21:00:33 <jaypipes> #startmeeting
21:00:34 <openstack> Meeting started Tue Feb 14 21:00:33 2012 UTC.  The chair is jaypipes. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:00:48 <jaypipes> Hello all, I'm filling in for ttx today.
21:01:06 <termie> hello jaypipes
21:01:12 <jaypipes> Based on some input from ttx, I'd like to mostly focus today on Keystone redux + Nova.
21:01:39 <jaypipes> so... unless notmyname, you have anything urgent to bring up, I'd like to move that Glance and Swift be skipped in today's meeting?
21:02:24 <anotherjesse> notmyname: I'd love to get your input on https://review.openstack.org/#change,3712 in #openstack-dev
21:02:29 <jaypipes> as a quick status update, Glance has a few bugs, but nothing major and is tracking fine for E4 thx to good work from Eoghan Glynn, Stuart McLaren and others
21:02:56 <jaypipes> anotherjesse: is swift the only CLI tool left to standardize?
21:03:09 <anotherjesse> jaypipes: YES! :)
21:03:17 <anotherjesse> happy dance
21:03:19 <jaypipes> anotherjesse: ah, nice work dtroyer!
21:03:36 <jaypipes> OK, termie, ready to chat about redux?
21:03:40 <jaypipes> anotherjesse: and you :)
21:03:45 <termie> yup
21:03:49 <jaypipes> k
21:04:05 <termie> Current Keystone (redux) Status!
21:04:13 <termie> do we need to do some thing with the meeting topic
21:04:18 <termie> to make the bots happy
21:04:20 <jaypipes> so, ttx has some valid concerns about the merge-readiness of the redux branch in relation to the ongoing feature freeze.
21:04:28 <jaypipes> #topic Keystone Redux status
21:04:54 <jaypipes> termie: ttx was looking for an overall status on redux and a description of any blockers
21:05:03 <termie> ready whenever you are
21:05:21 <termie> (if you are done prefacing the question)
21:05:27 <jaypipes> termie: yes, please go ahead
21:05:35 <termie> Current Keystone (redux) Status!
21:06:09 <anotherjesse> the suspense is killing me
21:06:21 <termie> we planned on haaving the marge prop in flight this morning, however due to some setbacks in the CI world most of our patches from yesterday are only now landing
21:06:34 <termie> we previously discussed a list of blockers, all of which are addressed by the patches in the queue
21:06:51 <termie> once they land we'll ask jeblair to nicely re-roll the merge prop
21:06:54 <termie> form redux to master
21:07:05 <anotherjesse> the primary focus of the patches were migration paths from diablo 5, diablo final and essex to redux
21:07:16 <jaypipes> k
21:07:34 <jaypipes> termie, anotherjesse: is https://review.openstack.org/#q,status:open+project:openstack/keystone+branch:redux,n,z an accurate depiction of remaining items to go in?
21:07:58 <termie> yep
21:08:03 <jaypipes> termie, anotherjesse: and I see quite a few bugs tagged with redux: https://bugs.launchpad.net/keystone/+bugs?field.tag=redux
21:08:05 <termie> and https://bugs.launchpad.net/keystone/+bugs?field.tag=redux
21:08:14 <termie> those marked "critical" the blockers
21:08:14 <anotherjesse> jaypipes: I believe so - the major deltas that might block merge is what state of XML support people require before the merge vs before E4
21:08:26 <termie> all of which are either committed or waiting on CI
21:08:28 <jaypipes> termie, anotherjesse: the two critical bugs that are in New status...
21:08:43 <jaypipes> termie: let's take the bugs one at a time... one sec
21:08:44 <termie> jaypipes: both committed or in the queu
21:08:57 <jaypipes> #link https://bugs.launchpad.net/keystone/+bug/928558
21:08:58 <uvirtbot> Launchpad bug 928558 in keystone "remove keystoneclient functionality from keystone-manage" [Critical,New]
21:09:02 <anotherjesse> termie: want to update the https://bugs.launchpad.net/keystone/+bug/928558 (it has landed)
21:09:09 <jaypipes> termie: that one needs a status update? or...?
21:09:35 <anotherjesse> it was merged in https://review.openstack.org/#change,4095
21:09:36 <jaypipes> anotherjesse: this one: https://bugs.launchpad.net/keystone/+bug/931837 is Critical, but I'm not sure it's really critical (doc fix)
21:09:38 <uvirtbot> Launchpad bug 931837 in keystone "update docs to talk about keystone-manage & cli" [Critical,In progress]
21:09:39 <anotherjesse> added a comment
21:09:41 <termie> updated
21:09:43 <jaypipes> k
21:09:45 <jaypipes> cool, thx
21:09:59 <termie> the doc fix is already associated with a change in the queue
21:10:08 <jaypipes> termie: gotcha. thx
21:10:14 <anotherjesse> jaypipes: we wanted to make sure we had documentation for the differences (termie noted a couple tweaks and sleepsonthefloo is updating them now)
21:10:50 <jaypipes> anotherjesse: got it. just wasn't sure about the Critical priority, but if it's already in-flight, totally cool.
21:11:19 <anotherjesse> jaypipes: yeah, the large thing was hoping to make the documentation reflect reality
21:11:39 <anotherjesse> anotherjesse: to minimize confusion during the transistion process
21:11:39 <jaypipes> termie: is this one covered in the patch that has other docs in it? https://bugs.launchpad.net/keystone/+bug/928043
21:11:41 <uvirtbot> Launchpad bug 928043 in keystone "document how to configure keystone (redux) with swift auth" [High,Confirmed]
21:12:00 <jaypipes> anotherjesse: talkin' to yourself again? ;)
21:12:15 <termie> jaypipes: that is not in our blocker category but the general expectation is that nothing has changed
21:12:15 <anotherjesse> jaypipes: swift + keystone is a work in progress regardless of keystone implementation
21:12:42 <jaypipes> anotherjesse, termie: k
21:12:55 <anotherjesse> jaypipes: chmouel has been helping with the swift middleware & documentation
21:13:07 <vishy> o/
21:13:13 <jaypipes> termie, anotherjesse: ok, so looks like all critical and most high bugs are in progress or already taken care of...
21:13:39 <termie> jaypipes: that is our feeling as well
21:13:51 <anotherjesse> we've been doing pretty regular sweeps of keystone bugs to re-catagorize
21:13:51 <jaypipes> termie, anotherjesse: when do you expect the final merge prop?
21:13:58 <jaypipes> cool.
21:14:29 <termie> jaypipes: we think jeblair should be able to roll a new one within the next hour or so
21:14:33 <jaypipes> anotherjesse: and the devstack-related changes for redux? those all good? have we smokestacked it all yet?
21:14:40 <jaypipes> termie: excellent.
21:14:44 <anotherjesse> assuming no more gotchas in the CI environment I think within an hour to gerrit then an email to #openstack
21:15:01 <anotherjesse> jaypipes: we have been keeping a devstack branch in gerrit as well (it is used as the merge to redux gate)
21:15:02 <termie> jaypipes: the devstack changes are still going to require hand-holding, we have a new devstack branch but they are inter-dependent with the redux branch of keystone
21:15:24 <termie> jaypipes: but it has been being used as the gating branch and we have kept it up to date with amster
21:15:32 <jaypipes> OK, good to hear.
21:15:50 <termie> jaypipes: so when the merge is approved we'll have to get mtaylor or jeblair to ninja them both in at once
21:16:02 <anotherjesse> jaypipes: the only concerns I have with getting the merge in is: if the community thinks that XML is a blocker for mereg
21:16:14 <jaypipes> anotherjesse, termie: so, looks like you both have a great handle on redux stuff. Could I ask one of you to send a post to the ML when the merge goes through with an update for the cmomunity and what (if anything) it means to folks?
21:16:16 <anotherjesse> thus far I've not gotten any feedback saying that
21:16:40 <zul> ubuntu/debian packages should start appear tomorrow for what its worth
21:17:23 <termie> zul: cool!
21:17:27 <jaypipes> anotherjesse: had a question offline... about Swift + Keystone. Could you elaborate on what you meant by they are a work in progress above?
21:17:33 <zns> anotherjesse: are you still planning on sending an email to the ML to ask about XML? Seems like that idea has been abandoned if we're merging in an hour?
21:17:35 <anotherjesse> jaypipes: yes, as soon as mtaylor & termie are done with the merge prop we will send an email with - summary of open issues (xml, ldap), how to try it out (devstack branch), ...
21:17:44 <anotherjesse> zns: YEP!
21:18:01 <zns> anotherjesse: k. tx.
21:18:04 <jaypipes> anotherjesse: thx on email. that will be appreciated.
21:18:07 <anotherjesse> zns: proposing to merge in an hour, not merging …  the community can review −1 or −2 requiring xml
21:18:22 <zns> anotherjesse: excellent. Thanks.
21:18:58 <jaypipes> anotherjesse: had a question offline... about Swift + Keystone. Could you elaborate on what you meant by they are a work in progress above?
21:19:32 <anotherjesse> jaypipes: keystone + swift has been the slowest for us (as a community) to get working well together
21:20:04 <anotherjesse> hence the volume of questions about key+swift on the mailing list
21:20:10 <johnpur> anotherjesse: are there issues with keystone and swift 1.4.6?
21:20:53 <anotherjesse> johnpur: I don't think the issues have been with the projects, but the middleware & documentation
21:21:49 <devcamcar> which is funny since swift was the only project that supported multiple auth middlewares from the get go
21:21:49 <jaypipes> anotherjesse: I think what johnpur is looking for is whether the issues are real blockers to implementing Swift with a Keystone API-compatible identiity layer.
21:22:09 <johnpur> anotherjesse: thx. jaypipes: yes!
21:22:10 <anotherjesse> I know devstack has been putting the two together for months now,
21:22:18 <anotherjesse> https://github.com/cloudbuilders/devstack/blob/master/stackrc#L10 <- for instance we've been working on the middleware here
21:22:36 <jaypipes> aha.
21:22:36 <anotherjesse> johnpur: chmouel has been working on it from our side
21:23:15 <jaypipes> anotherjesse: to be clear, then, redux and KSL has had no influence on the Swift + Keystone stuff? These issues existed prior?
21:23:31 <anotherjesse> jaypipes: correct
21:23:35 <jaypipes> anotherjesse: k, thx
21:23:38 <anotherjesse> jaypipes: the contract between services haven't changed
21:23:43 <jaypipes> just want to understand completely.
21:23:57 <anotherjesse> so this was a pre-existing issue that folks from swift + rcb (and others) are working on
21:24:06 <jaypipes> alrighty. OK, does anyone have any Keystone stuff to bring up?
21:24:23 <jaypipes> #action anotherjesse to send post to ML after redux is merged into trunk explaining its impact
21:24:41 <jaypipes> vishy: you're on deck.
21:25:20 <vishy> k
21:25:34 <jaypipes> alrighty, on to Nova.
21:25:37 <jaypipes> #topic Nova Status
21:25:39 <jaypipes> #link https://launchpad.net/nova/+milestone/essex-4
21:25:42 <anotherjesse> johnpur: an email to the openstack list would probably be good to clear up questions.  Sicne if you have questions about keystone+swift I'm sure others do as well
21:26:16 <jaypipes> vishy: looking at #link above, looking pretty good for E4.
21:26:20 <johnpur> anotherjesse: +1
21:26:23 <vishy> agreed
21:26:32 <vishy> there are three outstanding FFes
21:26:36 <jaypipes> vishy: the two Blocked blueprints, any update on those?
21:26:48 <jaypipes> vishy: is the keystone export blocked on redux I assume?
21:26:50 <vishy> If they aren't merged by next week, I'm going to push them
21:26:55 <jaypipes> same with depr auth?
21:27:01 <zul> i need another +1 for the lxc block support btw
21:27:05 <vishy> jaypipes: they are blocked waiting for redux
21:27:09 <jaypipes> vishy: gotcha
21:27:11 <vishy> zul: post link
21:27:40 <zul> https://review.openstack.org/#change,3609
21:27:42 <vishy> so the netapp driver and zeromq both have outstanding changes needed
21:28:15 <vishy> zul: that was previously approved and failed a pep8, so just needs a rubber stamp
21:28:26 <vishy> the big question is the zones code
21:28:59 <jaypipes> vishy: before discussing zones, how about the libvirt/KVM one from nati2_ ? https://review.openstack.org/#change,3477
21:29:10 <vishy> oh has that not merged yet?
21:29:11 <jaypipes> vishy: looks like that one was pretty far along in reviews?
21:29:50 <vishy> jaypipes: yeah that should make it
21:30:02 <vishy> there was one outstanding issue.  I thought it had been handled but not quite yet
21:30:37 <jaypipes> vishy: ok, well looks like that should be able to get in shortly. let's discuss the zones, then, eh?
21:30:40 <jaypipes> comstud: around?
21:30:45 <comstud> jaypipes: yep
21:30:53 <jaypipes> comstud: update on the zones stuff?
21:30:58 <jaypipes> or vishy ..
21:31:07 <vishy> so the code is in review
21:31:13 <vishy> the concern is whether it is too broad
21:31:21 <vishy> I looked over it and the core changes are relatively minor
21:31:34 <vishy> a couple database migrations adding new fields
21:31:37 <nati2_> Yes I have fixed version on my laptop
21:31:51 <nati2_> After testing it, I'll do review request again
21:31:58 <jaypipes> nati2_: k, thx
21:31:59 <comstud> 1 of the migrations is to the zones table itself
21:32:00 <vishy> and a few changes in compute.api
21:32:08 <comstud> the other migration is 1 column added to instances
21:32:14 <vishy> IMO these are fine to go in
21:32:23 <vishy> the rest of the code is all separate
21:32:27 <comstud> the compute.api change is just moving code into a separate method
21:32:29 <vishy> so here is what i'm thinking
21:32:42 <vishy> comstud: can you split into two patches?
21:32:43 <comstud> there's an openstack API change regarding network cache
21:32:58 <vishy> one with core changes and the second with all of the added stuff?
21:33:02 <comstud> I can.. if you want nova/zones/* a separate patch
21:33:02 <comstud> yeah
21:33:08 <vishy> lets get the core stuff in right away
21:33:12 <comstud> that's easy
21:33:18 <vishy> then the other stuff can go in if necessary
21:33:33 <vishy> we just have to make sure that we let people know that the feature is expiremental
21:33:34 <markwash> I have a few questions about getting this in
21:33:37 <comstud> so, the instance migration is a part of the core ?
21:33:40 <jaypipes> do we have updates to documentation that are needed for this? cc annegentle
21:33:47 <comstud> zones migration is 2nd patch or 1st?
21:33:58 <vishy> comstud: I would do the migrations in the first
21:34:07 <comstud> good
21:34:07 <jaypipes> markwash: pls do speak up :)
21:34:13 <annegentle> jaypipes: there's no doc that I know of
21:34:30 <comstud> there's some documentation in the nova code base itself
21:34:36 <vishy> we need to remove all of the references to the old zones code
21:34:38 <comstud> which gets removed in the 'zone removal' branch
21:34:43 <jaypipes> comstud: no, I was referring to docs in doc/source
21:34:46 <markwash> so #1, I'm wondering if the motivation for getting this in is really there if it is experimental and no one is presently extensively functional testing it
21:34:47 <comstud> vishy: done. in sandy's branch
21:34:53 <vishy> comstud: good
21:35:00 <jaypipes> markwash: excellent question.
21:35:03 <markwash> maybe it is, I dont know as much about the deployers who want it in essex
21:35:13 <annegentle> comstud: one concern I had was the name change in the code - everything's now named zones. It's like a big barrier to understanding to begin with, to me.
21:35:25 <markwash> rackspace of course is not limited to letter releases
21:35:25 <jaypipes> annegentle: ++
21:35:27 <annegentle> comstud: "name change" I mean is it zones
21:35:31 <vishy> markwash: the 2nd patch can wait for folsom afaic
21:35:38 <comstud> annegentle: we may want to leave it 'zones' for essex to make it easier
21:36:03 <jaypipes> comstud: I think that is a good idea.
21:36:13 <vishy> markwash: but the code will hard to maintain separately otherwise
21:36:20 <markwash> comstud: I definitely think zones is confusing, but I also think changing it could be more confusing at the moment
21:36:28 <comstud> markwash: nod
21:36:30 <markwash> edit: the name "zones"
21:36:32 <vishy> markwash: so FFeing the minor core changes to make it work seems fine
21:36:34 <comstud> markwash: i don't want to change it on a whim
21:36:58 <vishy> markwash: as for the new code, it could go in a branch
21:37:15 <comstud> vishy: I can live with that.. I'm going to change a FLAG name to match the new branch, also, though.  FLAGS.
21:37:27 <comstud> FLAGS.enable_zone_routing -> FLAGS.enable_zones
21:37:27 <vishy> comstud: that seems fine
21:37:30 <markwash> what are we considering "core" in the change, again?
21:37:43 <vishy> db migrations
21:37:49 <markwash> ah, okay
21:37:50 <vishy> api change to network cache
21:38:01 <comstud> markwash: the 2 DB migrations, the minor change to OS API for network cache, and I moved some code in compute.api into a new method
21:38:05 <vishy> minor change to compute api (which is just better error recovery)
21:38:24 <vishy> you cool with that plan markwash?
21:38:53 <markwash> I like that better, I'm still curious about whether or not the deployers clamoring for this really want an experimental implementation
21:39:39 <markwash> I'm sort of playing devils advocate on the "experimental" thing
21:39:42 <vishy> markwash: the main one is mercadolibre
21:39:57 <vishy> markwash: and their other option is to write something themselves
21:40:06 <vishy> which isn't good for anyone
21:40:21 <vishy> but they said they were happy experimenting using a branch
21:40:28 <comstud> i don't have a problem keeping a branch updated for a couple months until F opens
21:40:39 <markwash> so we might basically collaborate with them on the branch?
21:40:41 <comstud> the DB migrations are my main concern about keeping it working
21:41:03 <vishy> that was the hope yeah
21:41:13 <jaypipes> comstud: yes, but if the mirgations are done in patch 1 (and into trunk branch), then things are good, right?
21:41:28 <comstud> jaypipes: Yep, that solves my issue
21:41:35 <markwash> I like this plan. The core changes seem like a good foundation for us to continue to build out and prove the zones implementation
21:41:44 <jaypipes> then I think that makes the most sense
21:41:46 <anotherjesse> comstud: if we kept the branch open until F, would we still remove the existing zone stuff?
21:42:11 <comstud> anotherjesse: sounds like it (the existing stuff) should stay in essex
21:42:20 <markwash> I think removing existing zones adds a fair performance gain to the api
21:42:21 <vishy> :(
21:42:29 <comstud> alhtough
21:42:33 <comstud> i'd really love to remove it ;)
21:42:40 <vishy> i really don't want people using the zones stuff if we are trashing it
21:42:40 <markwash> and a good deal of complexity removed from the codebase
21:42:44 <anotherjesse> comstud: can we "remove" it by removing the API (not the code)
21:43:01 <comstud> vishy: Good to hear.. I'd love to remove it
21:43:09 <anotherjesse> I agree with vishy: having people deploy it in F would mean we would have to support it
21:43:14 <comstud> it cleans things up considerably
21:43:24 <comstud> s/F/E/?
21:43:43 <vishy> ok to summarize
21:43:56 <vishy> 1) remove old zones code (approve sandy's branch)
21:44:14 <vishy> 2) comstud splits core changes out of his patch and proposes
21:44:28 <vishy> 3) FFe for comstud's branch
21:44:49 <vishy> 4) added zones code goes into a separate branch
21:44:57 <anotherjesse> 5) critical bug update python-novaclient to remove zone stuff?
21:45:07 <anotherjesse> (or at least hide it)
21:45:10 <jaypipes> anotherjesse: ++
21:45:21 <comstud> remove it.. most of it will be not needed in new version
21:45:34 <comstud> s/most/all/
21:45:41 <vishy> agreed
21:46:03 <comstud> I will be re-adding a zones extension, but it'll provide some different functionality
21:46:19 <anotherjesse> vishy / comstud - need to alert Anne / doc team to remove zone from docs (if it was ever doc'd)
21:46:38 <jaypipes> k, vishy would you mind sending a short post to the ML summarizing the above and the outlined steps that are to be taken?
21:47:18 <jaypipes> vishy: of course, emphasizing that we're doing this to ensure long-term stability of the code base for service deployers, etc...
21:47:34 <markwash> this all sounds great to me
21:47:57 <annegentle> anotherjesse: really doc's all in the code, so far, but we could make it a priority for Doc Day if needed
21:48:17 <vishy> jaypipes no problem
21:48:21 <jaypipes> cheers
21:48:37 <jaypipes> vishy: k, any other things you'd like to highlight in Nova-land before we move on?
21:48:41 <jaypipes> devcamcar: you're on deck...
21:49:46 <jaypipes> alrighty, onwards to Horizon...
21:49:51 <jaypipes> #topic Horizon Status
21:49:53 <jaypipes> devcamcar: ping
21:49:56 <devcamcar> o/
21:50:11 <jaypipes> #link https://launchpad.net/horizon/+milestone/essex-4
21:50:20 <jaypipes> devcamcar: status report?
21:50:24 <devcamcar> so we are moving right along - today we want to take a moment and talk about design in general
21:50:49 <devcamcar> paul tashima has been working on the human interaction guidelines which outlines general design decisions that the community has made
21:50:53 <devcamcar> paul want to jump in?
21:50:55 <PaulTashima> sure
21:51:14 <PaulTashima> so we are currently trying to formulate the best way to create a process for design for the openstack project
21:51:26 <PaulTashima> the current idea can be viewed here: http://bit.ly/zjbuFQ
21:51:49 <PaulTashima> to help implement this process we've been working on the human interface guidelines doc to create evaluation criteria
21:51:55 <PaulTashima> https://github.com/4P/Horizon-HIG
21:52:34 <PaulTashima> we also have the current dashboard model documented (though slightly out of date): http://bit.ly/vgMmiA
21:52:37 <devcamcar> our goal with all of this is so that other teams can help contribute to horizon and make sure their projects are well represented
21:52:48 <annegentle> devcamcar: ++
21:53:06 <PaulTashima> yeah, hopefully this process will unify the user experience for openstack
21:53:18 <jaypipes> nice stuff, guys!
21:53:25 <PaulTashima> feel free to provide any kind of feedback on this stuff
21:53:30 <devcamcar> and for us to not be the bottleneck for design - this way we can set the foundation and guidelines and make it much easier for others to jump in and know they are using the right approaches
21:53:49 <jaypipes> PaulTashima: great start. I encourage you to share with the mailing list.
21:53:58 <PaulTashima> cool, thanks!
21:54:06 <devcamcar> we will definitely be getting feed back as well on ML
21:54:37 <jaypipes> awesome.
21:54:57 <devcamcar> any questions for us this week?
21:55:01 <jaypipes> devcamcar: re: the E4 milestone, there are a ton of Confirmed bugs...
21:55:21 <jaypipes> devcamcar: and a bunch of Not Started blueprints
21:55:47 <devcamcar> jaypipes: yes there are a number that are nice to haves and not necessary for essex. i'll be re-triaging this week and moving out a few of the visual enhancements to folsom
21:55:49 <jaypipes> devcamcar: probably good to re-target some of them to a later milestone?
21:55:53 <devcamcar> exactly
21:56:01 <jaypipes> devcamcar: gotcha.
21:56:08 <devcamcar> our goal is to have a solid functioning and polished version out for essex
21:56:15 <devcamcar> we'll add more fancy craziness for folsom
21:56:44 <jaypipes> excellent. I noticed the testing system was overhauled today
21:56:51 <jaypipes> looked like a good refactoring.
21:57:08 <devcamcar> yes, a lot of effort has gone into improving test coverage in essex
21:57:39 <jaypipes> devcamcar: FWIW, I've created a blueprint for separating the Glance client into its own package/project. Hoping that F1 timeframe that will  be done.
21:58:04 <jaypipes> devcamcar: that should help Horizon -- at least with dependencies and such.
21:58:06 <devcamcar> awesome :)
21:58:25 <jaypipes> devcamcar: and dtroyer has done an excellent job aligning all the CLIs authentication.
21:58:35 <jaypipes> dtroyer: ty!
21:58:39 <devcamcar> thanks dean!
21:59:06 <devcamcar> horizon is the team that gets to find all the discrepencies in how all the clients work
21:59:14 <devcamcar> so that is always appreciated
21:59:40 <jaypipes> OK, on a final note, I'm not sure about the status of the design summit. I believe ttx will be sending a note out in the next week or so explaining the invitation process and any changes from Boston that have occurred.
22:00:45 <jaypipes> Our little community has grown quite a bit, and there is only so much room at the design summit, so I expect there will be some disappointments as far as how many folks can actually go. But, c'est la vie with a growing project such as ours.
22:01:08 <jaypipes> Alright everyone, time to wrap up. See you on the ML.
22:01:13 <jaypipes> #endmeeting