16:00:11 <dhellmann> #startmeeting oslo
16:00:12 <openstack> Meeting started Fri Jul 25 16:00:11 2014 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:15 <openstack> The meeting name has been set to 'oslo'
16:00:17 <salv-mobile> Aloha
16:00:22 <dhellmann> who's around for the oslo meeting?
16:00:23 <beekneemech> o/
16:00:25 <zzzeek> im here
16:00:25 <dhellmann> hi, salv-mobile
16:00:32 <jecarey> o/
16:00:51 <i159> o/
16:01:25 <dhellmann> ok, good, let's go ahead and start
16:01:27 <rpodolyaka> o/
16:01:33 <dhellmann> #topic Review action items from previous meeting
16:01:33 <dolphm> o/
16:01:36 <zzzeek> o/
16:01:54 <dhellmann> I had no actions recorded from last time. Did I miss something in my notes?
16:02:21 * beekneemech has done no actions since last time. :-)
16:02:28 <bknudson> hi
16:02:35 <viktors> hi
16:02:41 <dhellmann> ok, I'm going to trust my notes, then :-)
16:02:41 <beekneemech> Actually that's not true.
16:02:45 <i159> no merges from me, all in progress
16:02:54 <beekneemech> I pawned off my graduation work on other people. ;-)
16:03:00 <dhellmann> haha
16:03:00 <morganfainberg> o/
16:03:11 <dhellmann> nice job of *delegating* beekneemech :-)
16:03:17 <dhellmann> #topic Red flags for/from liaisons
16:03:22 <beekneemech> Any time :-)
16:03:22 <dhellmann> how are things looking this week?
16:03:39 <bknudson> none here
16:04:01 <zzzeek> im wondering if the exception change in oslo.db is going to start impacting other projects
16:04:06 <bknudson> I don't know what a red flag would be at this point
16:04:13 <zzzeek> as our wrapped exceptions are showing up in migration tests now :)
16:04:15 <bknudson> ok, that would be a red flag
16:04:16 <dhellmann> zzzeek: yes, I would expect that to
16:04:31 <zzzeek> was just talking to someone about glance and a particiular exception being caught in a migration is being impacted
16:04:34 <dhellmann> zzzeek: have we released that version of the lib?
16:04:43 <zzzeek> dhellmann: no i belivev this is a devstack
16:04:45 <rpodolyaka> not yet
16:04:54 <dhellmann> zzzeek: ok, that's what I thought
16:05:02 <zzzeek> dhellmann: so ppl are going to start seeing it
16:05:12 <zzzeek> and we’ll be getting more exceptoin types added in
16:05:14 <dhellmann> do we have a list of the exceptions that changed so we can go hunt for them in the other projects?
16:05:36 <dhellmann> since the exceptions represent part of the API, we need to be extremely careful about making changes there
16:05:39 <zzzeek> dhellmann: in theory its every DBAPI exception
16:05:46 <i159> I pushed fix for keystone, to the exceptions wrappers problem
16:05:58 <viktors> we need this get this merged in keystone - https://review.openstack.org/#/c/108935/
16:05:58 <bknudson> i159: link?
16:06:07 <viktors> bknudson: ^^
16:06:28 <dhellmann> we need to make similar changes in all of the other projects
16:06:48 <viktors> dhellmann: I madefor Ironc, it got merged now
16:06:49 <i159> bknudson: yep, this is the link from Viktor
16:06:51 <zzzeek> yes.  but if those projects all have proper coverage for said execptions, we should be seeing it all
16:07:23 <dhellmann> zzzeek: yes, but if we're breaking the gate, people are going to get angry, so let's not change any other exceptions until we know what the impact will be and we can prepare patches in the other projects
16:07:27 <beekneemech> That's a scary "if"
16:07:44 <dhellmann> and yeah, we can't assume coverage is going to catch them, we need to look for them by hand
16:07:55 <zzzeek> dhellmann: OK this is the thing.   all exceptions other than OperationalError are now wrapped, whereas before, none of them were, within the scope of migrations
16:08:10 <dhellmann> does this only apply to migrations, then, and not runtime?
16:08:15 <zzzeek> dhellmann: it used to be, only ORM sessions wrapped exceptions.  now its all database connections
16:08:40 <zzzeek> i bring up migrations because that’s the key place that we arent using the Session and hence a change in behavior
16:08:42 <dhellmann> to be clear, that sounds like a good change, I'm just worried about how we roll it out
16:09:07 <zzzeek> the change is already out there, for every project that uses oslo.db.sqlalchemy.session.get_engine to connect
16:09:09 <rpodolyaka> yeah, this is something we always wanted to do, but couldn't...
16:09:38 * beekneemech thinks the change should go in next week ;-)
16:09:52 <zzzeek> waht we’re seeing in glance is some version of psycopg2 is raising a ProgrammingError and not an OperationalError
16:09:59 <zzzeek> and so it is being wrapped differently
16:10:19 <zzzeek> because we allow OperationalError through, but not ProgrammingError, which becomes DBError
16:10:30 <zzzeek> in the case of a constraint that is not found
16:10:44 <dhellmann> ok, I need one of you to put together a report about what driver-specific exceptions are being caught in the projects that will be affected by this change so we can make get the liaisons to work with us on fixes -- we can't break it and wait for bug reports, guys!
16:11:04 <beekneemech> +1
16:11:16 <beekneemech> +2 even
16:11:43 <dhellmann> viktors, rpodolyaka , zzzeek : work together on that, please
16:11:43 <zzzeek> dhellmann: OK we can grep
16:11:52 <dhellmann> ok, thanks
16:12:09 <rpodolyaka> dhellmann: sure!
16:12:09 <viktors> dhellmann: ok, sure
16:12:30 <dhellmann> #action viktors, rpodolyaka, zzzeek to prepare report about db driver-specific exceptions caught in integrated and incubated projects and what changes will be needed to handle the new wrapped exceptions from oslo.db
16:12:55 <dhellmann> ok, any other issues to talk about this week?
16:13:52 <dhellmann> moving on, then
16:13:54 <dhellmann> #topic Adoption status
16:14:00 <dhellmann> #link https://etherpad.openstack.org/p/juno-oslo-adoption-status
16:14:39 <dhellmann> what's up with the Tuskar patch for oslo.db being abandoned? did someone else pick that up, or is there an issue?
16:15:24 <viktors> dhellmann: they do not want to work with database at all
16:15:26 <bknudson> "The most likely current plan is to change Tuskar so it doesn't have its own database."
16:15:40 <viktors> dhellmann: See https://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning#Overcloud_Planning_and_Deployment
16:15:44 <dhellmann> ah, ok
16:15:45 <beekneemech> Oh, right.
16:15:55 <bknudson> all projects should have that goal
16:16:34 <dhellmann> #action dhellmann approach the other integrated projects who have not started work on oslo.i18n
16:17:28 <dhellmann> I don't see a patch for ceilometer to use oslo.db, did that work stall out?
16:18:01 <viktors> dhellmann: I see a single unmaintained
16:18:15 <viktors> I asked Alexei to work on it
16:18:16 <dhellmann> viktors: could you add the link to the etherpad?
16:18:20 <dhellmann> ok
16:18:23 <viktors> dhellmann: ok
16:18:27 <dhellmann> viktors: thanks
16:18:39 <dhellmann> #topic Spec status
16:18:48 <dhellmann> #info pylockfile adoption - https://review.openstack.org/#/c/102202/ (jd__) - team needs to vote on adopting the lib
16:19:00 <dhellmann> jd__, are you around to talk about that?
16:19:23 <dhellmann> I know this isn't a great time for our european members :-/
16:20:11 <dhellmann> based on the last comments i looked at on that review, I think we agree on the approach. I'll ask jd__ to post to the mailing list about it so we can vote there
16:20:23 <dhellmann> #action jd__ post about pylockfile adoption to the mailing list
16:20:34 <dhellmann> #info policy configuration directories - https://review.openstack.org/#/c/104157/ - needs review
16:21:10 <dhellmann> there were some comments from the keystone team about an alternate approach that sounded like a longer-term solution than this, so I would like for us to consider this smaller change
16:21:26 <dhellmann> bknudson, dolphm, do you have any input on that?
16:22:15 <dolphm> dhellmann: only that this is something we've certainly talked about recently...
16:22:46 <dolphm> dhellmann: and the direction that we see a lot of value in is definitely centralizing policy *storage* into keystone (not enforcement)
16:23:10 <dhellmann> dolphm: is it likely to be finished in juno? I'm thinking this directory change may be a convenience until the other projects adopt that central storage solution.
16:24:14 <dolphm> dhellmann: agree, i don't see any reason to -2 this effort or anything. policy management is somewhere where we have a lot of room to grow, and it's honestly not clear to me what the long term direction is (beyond the nice-to-have use cases that we've discussed)
16:24:27 <dhellmann> ok, good
16:24:38 <dhellmann> so we'll go ahead and review this spec and proceed as usual
16:24:43 <bknudson> I don't see how this could conflict with anything keystone's doing
16:25:03 <dolphm> bknudson: ++, we'd just be providing an alternative deployment option at some point
16:25:07 <dhellmann> yeah, the idea was not to spend time on it if it was going to be replaced with something else soon
16:25:21 <dhellmann> it sounds like that's not the case
16:25:22 <dolphm> dhellmann: definitely not in juno
16:25:25 <dhellmann> ok
16:25:41 <dhellmann> #topic Moving openstack/pycadf to the (proposed) TripleA program (dolphm)
16:25:45 <dhellmann> dolphm, the floor is yours
16:25:48 <dolphm> dhellmann: thanks
16:26:13 <dolphm> so, before we brought up this discussion to the TC, i wanted to bring this up with the keystone community and the oslo community
16:26:33 <dolphm> we had a similar topic in the keystone meeting earlier this week, http://eavesdrop.openstack.org/meetings/keystone/2014/keystone.2014-07-22-18.02.html
16:27:08 <dolphm> i've put up a proposed change to openstack/governance..
16:27:10 <dolphm> #link https://review.openstack.org/#/c/108739/
16:27:43 <dolphm> the gist is that we've seen the audit effort in openstack grow out of keystone's existing community, primarily around pycadf
16:28:14 <dolphm> so it seems appropriate to us that we roll it into keystone's program, which would also represent a slight expansion in scope (adding audit)
16:28:39 <bknudson> pycadf is essentially just a library?
16:28:42 <dhellmann> the other team that uses/contributes to that library is ceilometer, so you might find interested cores there, too
16:29:06 <dolphm> i wanted to bring it up here first to ask if anyone had any concerns/disagreement with that direction- i.e. should pycadf stay in oslo? should the identity program not expand it's scope to include audit?
16:29:31 <dolphm> dhellmann: it's funny you should mention ceilometer actually...
16:29:57 <dhellmann> I think if the program scope expands it does make sense to move the library. That also solves our problem that gordc is stepping down as primary maintainer.
16:30:16 <bknudson> does pycadf have its own core team?
16:30:24 <dhellmann> I think so, let me check
16:30:25 <dolphm> in a lot of larger organizations, you'll see "AAA" oriented teams that cover authN, authZ and "accounting" - where "accounting" includes quota, usage monitoring, and auditing
16:30:42 <dhellmann> bknudson: https://review.openstack.org/#/admin/groups/192,members
16:31:05 <dolphm> bknudson: technically, yes.. but that looks like just ^ oslo core if i'm not mistaken?
16:31:28 <bknudson> I'm guessing matt rutkowski isn't a general oslo core...
16:31:33 <dhellmann> it started out as a stackforge project, and some of the contribs are oslo core, but some are not
16:31:33 <dolphm> ooh, i'm definitely mistaken
16:32:02 <dolphm> afaik, gordon chung has been the most active contributor to pycadf, but he no longer works on openstack (?)
16:32:20 <dhellmann> that library has been looking for a good home since it was created. at that time, the ceilometer team didn't want to own it, but we did have some input
16:32:33 <bknudson> topol will find someone else to maintain it
16:32:50 <dhellmann> I thought he was just changing jobs and the new company wanted him to focus on other things, but I could be mistaken.
16:33:15 <dhellmann> well, you all clearly have interest and so I think on those grounds it makes sense to move it
16:33:35 <dhellmann> we don't have a quorum of our cores here to vote, so dolphm would you start a discussion on the ML?
16:33:40 <bknudson> I'm just wondering what happens to the core team in the switch
16:33:55 <dolphm> dhellmann: yes, the ML was my next step, prior to asking for a TC vote
16:34:06 <dhellmann> I would expect keystone-core to be added, and anyone from oslo-core who wants to stay on to be added individually so oslo-core can be removed
16:34:19 <dolphm> bknudson: happy to hear input on that
16:34:36 <bknudson> I think dhellmann's suggestion is the right way to go
16:34:48 <beekneemech> +1
16:34:53 <dhellmann> we have found it very useful to have separate core teams for libraries, so if someone is focused just on one area they can contribute there without feeling pressure to do the same across the other repos
16:35:04 <dhellmann> keystone's team may be more focused than oslo, though, by its nature
16:35:39 <dolphm> sounds good to me; follow up with julien and matt to find out if they have interest in staying on as cores (i assume neither are present right now?)
16:35:49 <bknudson> some of this depends on what dolphm wants to do, since I would expect him to be choosing a different core team for pycadf
16:36:02 <dhellmann> #action dolphm start discussion on the mailing list to get feedback from the oslo team about taking over pycadf library
16:36:08 <bknudson> I'm fine with not being core on pycadf
16:36:27 <dhellmann> yeah, it's up to you all, I'm just offering input about what we've found to work well
16:36:46 <dhellmann> dolphm, was there anything else to discuss on this topic?
16:36:54 <dolphm> nope- that's all i have; happy to answer questions if anyone has any though
16:37:29 <dhellmann> let's do that in the ML discussion
16:37:34 <dolphm> ack, thanks!
16:37:44 <dhellmann> like I said, we're not really at quorum today, so you're likely to have to repeat yourself anyway
16:38:14 <dhellmann> ok, let's talk about my favorite topic: libraries!
16:38:15 <dhellmann> #topic oslo.utils graduation status
16:38:17 * dims wanders in with an apology for being late
16:38:21 <dhellmann> #link https://review.openstack.org/#/q/status:open+project:openstack/oslo.utils,n,z
16:38:27 <dhellmann> dims: you are *exactly* on time :-)
16:38:34 <dims> :)
16:38:40 <dhellmann> we have a few minor changes to oslo.utils to land before dims can cut the first release
16:38:55 <dhellmann> so good progress, and please take a look at those open changes
16:39:06 * beekneemech clicks
16:39:08 <dims> almost there!
16:39:11 <dhellmann> I would like to do the release by tuesday or wednesday next week, if we can
16:39:40 <dhellmann> since no one is using the library, yet, I guess we could cut the release whenever we want without breaking anything
16:39:47 <dims> right
16:40:38 <dhellmann> #topic oslo.serialization graduation status
16:40:45 <dhellmann> dims has a repo ready to import
16:40:46 <dhellmann> #link https://review.openstack.org/108861
16:41:08 <dhellmann> dims, is there anything else blocking that? I suspect it won't see any action until the infra team comes back from oscon
16:41:31 <dims> dhellmann, i created the pypi entry as well, dont think so
16:41:36 <dhellmann> ok, good
16:41:48 <dhellmann> #topic oslo.concurrency graduation status
16:42:23 <dhellmann> YorikSar took over this one. There was an issue with creating the repository, but I think we worked through that and he's able to continue.
16:42:28 <YorikSar> I've ran into some issues with graduate.sh and in process of fixing them.
16:42:57 <YorikSar> dhellmann: Yep. I'm thinking about saving more of our history (merge commits and original commiter and commit date)
16:42:57 <dhellmann> and you have some performance improvements to the graduate script as well, right?
16:43:07 <YorikSar> At least 10x :)
16:43:24 <dhellmann> YorikSar: ok, some of the details like that should be preserved if the script doesn't die because of the merge conflict :-)
16:43:57 <dhellmann> we were able to keep those details in the other new repositories, for example
16:44:06 <YorikSar> I've also created 2 change requests regarding lockutils: removing oslo.log and switching to sysv_ipc
16:44:36 <dhellmann> YorikSar: those sound like changes to make in the new library after graduation
16:44:51 <amrith> dhellmann, would it be appropriate to bring up the issue of merging https://review.openstack.org/#/c/109417/ prior to graduation; that was a point you raised in your code review yesterday.
16:44:56 <YorikSar> dhellmann: Hm... I thought they should be done in incubator first.
16:45:02 <dhellmann> and the sysv_ipc change sounds potentially big enough to want a spec
16:45:25 <dhellmann> amrith: yes, this is a good time to discuss that
16:45:47 <YorikSar> dhellmann: I don't have the wiki page opened here but it seemed to be that it says that at least oslo.log should be removed in incubator :)
16:45:52 <dhellmann> YorikSar: well, one of the carrots we have to encourage projects to adopt the new libraries is that they come with new features (like the sysv_ipc change)
16:46:11 <beekneemech> YorikSar: Yes.
16:46:12 <YorikSar> sysv_ipc change is actually a fix for a bug - it's not that big
16:46:25 <beekneemech> YorikSar: No!
16:46:29 <dhellmann> the logging change does make sense to do in the incubator, yes
16:46:31 * beekneemech stops speaking in monosyllables
16:46:49 <beekneemech> We've tried swapping out the lockutils backend multiple times.  It hasn't ended well once.
16:47:00 <YorikSar> beekneemech: Ok :)
16:47:10 <YorikSar> I'll wait for new repo then.
16:47:17 <beekneemech> I'm not saying it shouldn't be done, but it shouldn't be done without some careful thought.
16:47:19 <dhellmann> yeah, I'm not excited about going through that again without a lot of eyes on it, and that says "spec" and "kilo" to me
16:47:27 <beekneemech> +1
16:47:38 <beekneemech> Although lockutils is pretty broken right now.
16:47:40 <YorikSar> Btw, who should I set as maintainer and etc?
16:48:30 <dhellmann> YorikSar: look through the MAINTAINERS file to see who is listed for each module
16:48:56 <YorikSar> IIRC it says Michael Still
16:49:04 <dhellmann> yes, for lockutils that's correct
16:49:18 <YorikSar> And for processutils too.
16:49:19 <dhellmann> wasn't there another module in the lib? processutils, right?
16:49:21 <dhellmann> ok
16:49:34 <YorikSar> So I should leave it as is?
16:49:36 <dhellmann> we can ask mikal if he still wants to be listed as the maintainer in the library
16:49:45 <YorikSar> Ok, will do.
16:49:47 <amrith> thanks dhellman. https://review.openstack.org/#/c/109417/ is a localized change to processutils.py that masks passwords in cmd, stdout and stderr from making their way back up the stack in an exception. It is a security risk. I'd like oslo team to consider merging it ahead of oslo.concurrency graduation.
16:50:33 <YorikSar> Another question... I wonder why did other concurrency-related modules were left out of oslo.concurrency.
16:50:35 <dhellmann> YorikSar: do you have a clean repo you're happy with, yet?
16:50:36 <beekneemech> amrith: Agreed.  That either needs to be done before graduation or backported.
16:50:37 <amrith> I also suspect there will be requests to push this into older pre 'J' releases, and also cause the projects to pick them up.
16:50:47 <dhellmann> amrith: you might have *just* missed the opportunity to land that before graduation
16:50:55 <YorikSar> Like local, threadgroup, etc...
16:50:58 <dhellmann> we still want to do the work, but it might have to go into the library first now
16:50:59 <amrith> story of my life ;)
16:51:28 <dhellmann> YorikSar: I would have to look at the dependency list, but I think those are going into a service library instead because they are higher level constructs
16:51:30 <amrith> would you like me to merge into oslo.concurrency project, that doesn't seem right.
16:51:31 <beekneemech> YorikSar: I think it had something to do with the fact that those are very specialized.
16:51:44 <beekneemech> Like threadgroup is pretty specific to service.
16:51:44 <dhellmann> YorikSar: https://wiki.openstack.org/wiki/Oslo/GraduationStatus
16:51:51 <beekneemech> local is only used in log IIRC.
16:52:15 <dhellmann> amrith: you will need to resubmit the patch to oslo.concurrency and then you can back-port it to the incubator
16:52:39 <YorikSar> Hm... Ok, we can discuss that after the meeting, I guess. It looks like I've hijacked the time here.
16:52:43 <dhellmann> amrith: you could continue working on a patch in the incubator for now, but mark it WIP so we don't merge it until it goes into the library
16:52:47 <amrith> not a problem, is there a time (limit) on this oslo.concurrency patch submission?
16:53:02 <amrith> mark as WIP in incubator: wilco
16:53:06 <dhellmann> amrith: no, I don't think so, we don't have the gerrit stuff done yet
16:53:06 <YorikSar> dhellmann: Oh, I don't have a repo yet. I think I'll have one in an hour or two.
16:53:15 <dhellmann> YorikSar: ok
16:53:35 <dhellmann> that's less time than it would take to adequately review the patch and you would have to start over with the export
16:53:46 <dhellmann> we only have a few minutes, so I'm going to move on
16:53:52 * dhellmann prepares paste-bomb
16:53:53 <dhellmann> #topic Release review
16:53:54 <dhellmann> #info oslo.rootwrap 1.3.0.0a1 - https://etherpad.openstack.org/p/oslo-rootwrap-1.3.0
16:53:54 <dhellmann> #info oslo.messaging 1.3.1 - bug fix release for ceilometer team
16:53:54 <dhellmann> #info oslo.messaging 1.4.0.0a4 - https://etherpad.openstack.org/p/oslo.messaging-1.4.0
16:53:55 <dhellmann> It looks like it has been a long time since I released a new version of cliff, so I will do that on Monday
16:54:21 <dhellmann> we're going to hold off on olso.db releases until the exception change thing is worked out
16:54:42 <zzzeek> dhellmann: for showing large text file output in my search do you recommend etherpad
16:54:44 <dhellmann> and as we said before we hope for a 0.1.0 of oslo.utils next week
16:54:58 <dhellmann> zzzeek: yes, that would be a good place to keep the notes
16:55:02 <zzzeek> ok
16:55:07 <dhellmann> #topic review priorities for this week
16:55:07 <dhellmann> #info oslo.utils release blockers
16:55:07 <dhellmann> #link https://review.openstack.org/#/q/status:open+project:openstack/oslo.utils,n,z
16:55:07 <dhellmann> #info oslo.i18n doc updates
16:55:07 <dhellmann> #link https://review.openstack.org/#/q/project:openstack/oslo.i18n+is:open,n,z
16:55:24 <dhellmann> a few minor doc changes for oslo.i18n there, we should be able to land those quickkly
16:55:33 <dhellmann> is there anything else we need to prioritize?
16:56:18 <dhellmann> ok, I guess not
16:56:22 <dhellmann> #topic meeting next week
16:56:22 <dhellmann> I will be offline for a few days next week for vacation.
16:56:22 <dhellmann> Would someone like to volunteer to organize the meeting for us on 1 Aug?
16:56:56 <bknudson> we could all use a vacation
16:57:14 <dhellmann> well, that's true, but I didn't want to cancel just because I wasn't going to be here :-)
16:57:27 * beekneemech on vacation next week too
16:57:36 <dhellmann> dims, how about you?
16:57:54 <dhellmann> I'll pester people after the meeting
16:57:57 <dims> dhellmann, i'll be in Beaverton
16:58:04 <dhellmann> ah, right
16:58:07 <dims> i'll be out the week after
16:58:18 <dhellmann> ok, well, maybe we should cancel if most of us won't be here
16:58:25 <dims> +1
16:58:27 <dhellmann> markmc was going on vacation, too, I think
16:58:37 <beekneemech> Tis the season :-)
16:58:56 <dhellmann> #info meeting next week cancelled
16:59:00 <dhellmann> that was easy :-)
16:59:18 <dhellmann> #topic open discussion
16:59:18 <dhellmann> #info dhellmann's email address is changing from doug.hellmann@Dreamhost.com to doug@doughellmann.com
16:59:33 <dhellmann> please update your address books, as needed
16:59:50 <dhellmann> we have about a minute left, if there's anything else?
16:59:51 <bknudson> they finally gave you your own domain?
17:00:16 <dhellmann> bknudson: I'm changing employers
17:00:16 <dims> dhellmann, need some nova core cycles for oslo.vmware
17:00:21 <beekneemech> dhellmann: Would like to talk about cross-testing, but that can probably happen after the meeting.
17:00:23 <dims> dhellmann, congrats!
17:00:39 <dhellmann> beekneemech: I have another meeting right after, so maybe later today?
17:00:42 <dhellmann> dims: thanks :-)
17:01:02 <dhellmann> dims: ping jogo to help, he's our liaison
17:01:15 <dhellmann> ok, we're over time and I do have to run
17:01:16 <beekneemech> dhellmann: Maybe.  Might be heading to the airport early, depending on how the carpooling works out.
17:01:17 <dhellmann> thanks everyone!
17:01:25 <dhellmann> beekneemech: email?
17:01:37 <dims> have fun beekneemech
17:01:53 <dhellmann> #endmeeting