21:01:12 <mikal> #startmeeting nova
21:01:12 <mikal> #topic Introduction
21:01:12 <openstack> Meeting started Thu May  8 21:01:12 2014 UTC and is due to finish in 60 minutes.  The chair is mikal. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:13 <mikal> So, thanks everyone for coming to the first nova meeting for Juno. I think we have a lot of exciting work to do this cycle, so I’m pretty pumped about the opportunities before us. Please be gentle while I learn to drive meetbot.
21:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:14 <jogo> o/
21:01:16 <openstack> The meeting name has been set to 'nova'
21:01:16 <devoid> o/
21:01:18 <dansmith> o/
21:01:30 <alaski> hi
21:01:32 <melwitt> o/
21:01:36 <leifz> o/
21:01:43 <mikal> Its weird to me having one of these not at 7am
21:01:50 <tjones> hi
21:02:00 <mikal> That said, onto more specific things…
21:02:01 <mikal> #topic Upcoming summit
21:02:19 <mikal> The obvious thing for us to be prepping for is the summit next week. The nova track is over three days, and has 20 something sessions.
21:02:22 <mikal> danpb kindly pre-created all the session etherpads for us, which are at https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Nova.
21:02:38 <mikal> For people with accepted sessions:
21:02:38 <mikal> - if you have associated blueprints, please make sure your on top of the feedback on your spec review before the session
21:02:41 <mikal> - if your session doesn’t have any blueprints associated with it, should it?
21:02:44 <mikal> - please have an outline of what you want to discuss in your ether pad before the session (preferably at least the _day_ before)
21:02:59 <mikal> What other things do we need to do to prepare for the summit?
21:04:02 <devoid> Any nova-devs out there that are also operators, please contribute to the operators in design summit etherpad
21:04:10 <devoid> … digging up link...
21:04:19 <mikal> Yep, there's also a nova operators session that needs fleshing out
21:04:42 <mikal> I think the ether pad for that session would be the right place for people to contribute
21:04:43 <devoid> https://etherpad.openstack.org/p/juno-summit-ops-volunteer
21:04:44 <mriedem> can i put my question about dropping null instance uuid records on the nova operators session? :)
21:04:49 <mikal> devoid: I think we're talking about the same session?
21:04:57 <mikal> mriedem: that's a really good idea
21:05:05 <devoid> mikal: there is alos an effort to have operators in every design session.
21:05:33 <mikal> devoid: yep, the nova session is at https://etherpad.openstack.org/p/juno-nova-devops
21:05:42 <mikal> devoid: so if people have things that are nova specific I'd prefer they go there
21:05:50 <mriedem> cool, thanks
21:05:51 <mikal> Instead of trying to dig the nova bits out of another etherpad on the fly
21:05:51 <devoid> mriedem: yes
21:06:13 <mriedem> oh shazbot i'll be heading to the airport
21:06:15 <mriedem> oops
21:06:18 <mikal> I know that VW was also going to take a look at that session, but probabky not until later this week
21:06:27 <mriedem> maybe jaypipes can be my proxy :)
21:06:30 <mikal> mriedem: we could ask for you? If you remind us in the etherpad?
21:06:34 <mriedem> yeah
21:06:35 <jogo> devoid: has anyone given these ops a crash course on how the design summit works, to maximize there usefulness?
21:06:36 <devoid> mriedem: yea, dev/ops summit timing could have been better
21:06:43 <devoid> mriedem: just rescheduled my flights
21:06:54 <mikal> jogo: not that I am aware of, this is an experiement
21:06:57 <devoid> jogo: I can only speak for myself in this respect.
21:06:58 <jaypipes> mriedem: sure thing.
21:07:20 <jogo> because if this is there first design summit, a crash course would really help
21:07:29 <devoid> jogo: Tom's email was clear though: " Though, please note that you should do some preparation, like reading the associated blueprint, in order to avoid asking "beginners" questions ... developers have very limited time to get a lot done!"
21:07:29 <mikal> jogo: we can do a quick "what to expect" at the start of each day or somethign if that would help
21:07:47 <jaypipes> jogo: Tom and Tim have been discussing the summit format and expectations with the operators, yes.
21:07:53 <mikal> I think that's also my job is to reign in tangents when they happen
21:08:00 <devoid> jogo, mikal, I will try to convey any dev concerns you have during the monday ops meetings.
21:08:05 <jogo> ahh good, thanks
21:08:08 <mikal> Thanks
21:08:24 <mikal> Is there anything else for the summit?
21:08:37 <mikal> I just want to reinforce that good prep this week means we're all a little less busy next week
21:08:44 <devoid> I have a minor request for libvirt dev time, like 15 minutes to help me w/ my sheepdog blueprint
21:08:55 <devoid> not sure if that belongs in errata
21:09:08 <mikal> devoid: can we table that until open discssion at the end?
21:09:16 <devoid> mikal: yes, cool
21:09:21 <mikal> Thanks
21:09:31 <mikal> Although, I should point out there will be a nova "pod" in the dev lounge
21:09:40 <mikal> So people can hang out as a group in breaks etc
21:09:47 <mikal> Not sure if it has 200 seats though...
21:10:00 <mikal> So nothing else about the summit?
21:10:22 <mikal> #action devoid to make sure that ops have been briefed on how the design summits work
21:10:40 <mikal> #topic bugs
21:10:41 <mikal> Another thing I’d like to be tracking in these meetings is what high priority bugs people think we need to be looking at, or which have fixes out there waiting for a code review. Is there anything like that at the moment?
21:11:10 <jogo> mikal: I don't have a bug number but I have seen a bunch of quota issues being filed recently
21:11:21 <mikal> jogo: oh, interesting
21:11:22 <jaypipes> mikal: there's a bug triage day scheduled for th emonday after the summit...
21:11:29 <mikal> jogo: new bugs, or just people with a new use case?
21:11:34 <tjones> mikal: i'd like to chat with you at the summit to talk about bugs
21:11:46 <mikal> jaypipes: project wide you mean?
21:11:50 <mikal> tjones: I'd love that
21:12:00 <mikal> #action tjones and mikal to chat about bug triage at summit
21:12:04 <jaypipes> mikal: yes, I believe so. just lettin gyou know... SergeyLukjanov was organizing.
21:12:18 <jogo> mikal: new bugs
21:12:21 <mikal> jaypipes: its news to me, but I think it sounds like a good idea
21:12:42 <mikal> jogo: hmmm, when you get some numbers want to send them my way?
21:12:57 <jogo> https://bugs.launchpad.net/tripleo/+bug/1284424
21:12:58 <uvirtbot> Launchpad bug 1284424 in nova "nova quota statistics can be incorrect" [High,Confirmed]
21:13:03 <jogo> https://bugs.launchpad.net/nova/+bug/1297590
21:13:03 <mikal> jogo: or alternatively, is anyone looking at them already?
21:13:04 <uvirtbot> Launchpad bug 1297590 in nova "Quota leakage issue " [Undecided,New]
21:13:29 <mriedem> there are a few in progress patches for some quotas bugs i think
21:13:44 <mikal> #action Quota bugs: 1284424 1297590
21:13:44 <jogo> https://bugs.launchpad.net/nova/+bug/1301532
21:13:45 <mriedem> i usually associate comstud with quotas :)
21:13:47 <uvirtbot> Launchpad bug 1301532 in ossa "Quotas can be exceeded by making highly parallel requests" [Undecided,Won't fix]
21:13:57 <mikal> mriedem: heh, I think comstuf has escaped to ironic...
21:14:05 <mikal> comstud even
21:14:17 <mikal> #action Quota bugs: 1301532
21:14:17 <mriedem> there was also a db api race with getting quota values that i saw this weekend, but it's and old issue
21:14:32 <mikal> There are also a _lot_ of live migration bugs open at the moment, but most of them have been around a while
21:14:35 <mriedem> maybe we start tagging them?
21:14:42 <mikal> We just need someone to be systematic about fixing them all
21:14:48 <jogo> mikal: a hard thing with live migration is no gating on it
21:14:54 <mikal> jogo: agreed
21:14:58 <jogo> mriedem: ++ to tagging em
21:15:01 <johnthetubaguy> mikal: i did create a tag about that, I had planned to take a look
21:15:04 <mikal> jogo: and the number of storage / hypervisor permutations
21:15:17 <mikal> johnthetubaguy: for quota or live migration?
21:15:21 <mriedem> i think mtreinish and the QA boyz were looking at multi-node testing in the gate for juno?
21:15:24 <devoid> mikal: yes, tons of ways to do it
21:15:31 <johnthetubaguy> mikal: live-migrate, maybe it was unofficial at the time
21:15:51 <mikal> johnthetubaguy: oh, interesting. I wrote up a summary a month or so but haven't done anything else with it
21:16:08 <johnthetubaguy> mikal: kinda working through some of those issues with live-migrate, kinda half way through the refactor
21:16:09 <mikal> johnthetubaguy: but I'd be interested in sharing state with anyone wanting to take a look at them
21:16:19 <johnthetubaguy> mikal: but I think johannes was going to take a look
21:16:27 <mikal> johnthetubaguy: I'm scared of changing that stuff without fixing the gating issue
21:16:36 <dansmith> I made a change recently,
21:16:37 <mikal> I'd even settle for third party CI on it until we can get something in the gate
21:16:48 <dansmith> and Hans Lindgren manually tested my change for me in a real environment :)
21:16:53 <johnthetubaguy> mikal: yeah, its getting the two machine setup
21:16:55 <dansmith> it sucked, but I was *really* happy to have someone validate it :)
21:17:07 <mikal> Actually a multinode devstack isn't too bad
21:17:15 <johnthetubaguy> dansmith: yeah, thats all I have been doing
21:17:19 <dansmith> I think it's reserving pairs in nodepool
21:17:19 <mikal> That's how I tested that config drive live migration problem
21:17:31 <johnthetubaguy> mikal: yeah I have that on my laptop, but its just getting in gate is messier
21:17:37 <sdague> mikal: there is some basic hooks in nodepool now for multi node allocation
21:17:39 <mikal> I am _sure_ I saw a design summit session on multi node gating
21:17:49 <johnthetubaguy> sdague: awesome news
21:17:55 <mikal> If there is one, we should send some people to beg
21:17:59 <sdague> but it needs some real work to pull it all together
21:18:09 <sdague> mikal: I don't think we landed a multi node session
21:18:11 <mikal> sdague: is someone doing that work, or does it need a body?
21:18:14 <clarkb> sdague: mikal: and in theory nothing prevents doing it now. You just might need to setup openvpn and so on
21:18:20 <sdague> right now it needs a body
21:18:29 <comstud> mikal: I haven't fully escaped
21:18:39 <mikal> sdague: you could probably trick mattoliverau into taking a look
21:18:49 <mikal> sdague: he's been playing with the nodepool code a lot already
21:19:13 <sdague> mikal: will he be in atlanta?
21:19:21 <mikal> Definitely for juno I'd like to see some form of gating on live migration
21:19:24 <mikal> sdague: yes
21:19:36 <mikal> Even if it doesn't have 100% coverage
21:19:42 <devoid> out of curiosity, what kind of live-migration config?
21:19:43 <mikal> Anything is better than what we have now
21:19:46 <sdague> mikal: ok, make sure we find each other. I'll walk him through current thinking if he can dive on it early
21:19:56 <mikal> sdague: ok
21:20:20 <mikal> #action mikal to introduce mattoliverau to sdague for multi node dev stack in gate
21:20:29 <mikal> devoid: for gating you mean?
21:20:38 <devoid> mikal: yea, lots of ways to do it.
21:21:12 <devoid> also not clear if certain ways functionally work (e.g. shared storage w/ ceph, gluster, etc.)
21:21:13 <mikal> devoid: I think I'd like to see the tests refactored in a way where any new storage driver ends up requiring a test for it
21:21:28 <devoid> mikal: sounds good to me.
21:21:35 <mikal> devoid: ie, you get a tempest fail if you add a storage driver which doesn't work
21:21:47 <mikal> I don't 100% know what that looks like, but I think its a good goal
21:22:12 <mikal> So, any other bugs we should be tracking at the moment?
21:22:52 <mikal> #topic Blueprints
21:22:52 <mikal> Keystone V3 Support: https://blueprints.launchpad.net/nova/+spec/support-keystone-v3-api
21:22:57 <mikal> mriedem: this was you right?
21:23:01 <mriedem> mikal: yeah
21:23:10 <mriedem> so was wondering if anyone had heard of any progress there,
21:23:12 <mriedem> or plans to
21:23:19 <mriedem> there are several patches lined up behind keystone v3 support in nova
21:23:29 <mriedem> but not really sure what that is - besides what i have linked in the agenda
21:23:39 <mriedem> and we had this https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition
21:23:40 <jogo> mriedem: last I heard there is a keystone BP to document what is in v3 what is needed to upgrade nova etc
21:23:40 <devoid> mikal: there's a summit meeting on the testing matrix discussion, sounds like a good place for that.
21:23:42 <alaski> I have some work I'd like to line up behind it as well
21:24:17 <mikal> I am sitting next to the keystone PTL this week, I could ask him for his thoughts if you'd like
21:24:25 <jogo> mriedem: ahh yup
21:24:27 <mriedem> someone that works more on keystone was telling me their team sounded willing to help move the code in nova for keystone v3 as long as there were nova cores they could pair up with?
21:24:45 <jogo> IMHO we want https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition to be done first
21:24:50 <mriedem> jogo: yeah
21:24:52 <mriedem> that
21:24:52 <jogo> before anything else lands etc
21:24:54 <mikal> That's kind of what happened with the cinder API bump, but we did a poor job of hand holding
21:25:05 <mriedem> jogo: then probably this https://blueprints.launchpad.net/tempest/+spec/multi-keystone-api-version-tests
21:25:14 <devoid> keystone needs a bunch of doc help, from the operator perspective
21:25:54 <mikal> devoid: probably true, but let's focus on nova here
21:25:54 <jogo> mriedem: agreed
21:25:58 <mriedem> anyway i guess we start the ball rolling with dolphm and https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition
21:26:30 <morganfainberg> mriedem, i know dolphm said he was aiming to work on that this week
21:26:31 <mikal> So... Is someone talking to keystone people about this alreayd?
21:26:57 <mriedem> mikal: i'm sort of kind of trying...when i remember
21:27:06 <mikal> Heh
21:27:12 <mriedem> if bknudson can work on it then i can work with him
21:27:14 <mriedem> he sits down the hall
21:27:25 <mikal> Ok, I will ping dolphm about it over coffee tomorrow
21:27:38 <melwitt> I was under the impression that only the clients were blocking adoption of keystone v3 api. sounds like there's more involved
21:27:39 <mikal> But it bknudson and mriedem wanna drive it that sounds super good to me
21:27:53 <mikal> melwitt: well, I think we're mostly asking for documentation, right
21:27:55 <mikal> ?
21:28:16 <morganfainberg> melwitt, it's a bit more involved making sure everything works as expected, but documentation is the first step that was agreed upon
21:28:16 <bknudson> we discussed assigning a keystone core member to each proj to help with the transition
21:28:18 <mikal> #action mikal to ping dolphm about keystone v2 to v3 transition (documentation, who will do the nova work)
21:28:21 <morganfainberg> melwitt, and the clients are a bit part of it.
21:28:24 <morganfainberg> bknudson, ++
21:28:38 <melwitt> mikal, morganfainberg: understood
21:28:59 <mikal> Any other blueprints we should be talking about? I suspect most are blocked on the summit?
21:29:18 <johnthetubaguy> everyone OK with the new process?
21:29:31 <jogo> I have some concerns actually
21:29:52 <mriedem> is nova-specs stagnating?
21:29:52 <johnthetubaguy> jogo: do fire away
21:29:56 <mikal> jogo: do tell
21:30:01 <jogo> mainly I think this new process may result in a dramatic cut in the number of BPs we can approve
21:30:11 <dansmith> that's good, IMHO
21:30:36 <jogo> icehouse had 67 BPs implimented  https://blueprints.launchpad.net/nova/icehouse
21:30:42 <mikal> I don't want to see process for process' sake
21:30:50 <mikal> But I do think we're coming up with better thought through designs now
21:30:59 <jogo> I think the new process is really good and not for processes' sake too though
21:31:08 <leifz> 23 approved right now?
21:31:09 <jogo> just think we need more eyes on the nova-specs patches
21:31:13 <melwitt> so far I've liked the process in that it makes it easy to find which bps need to be reviewed and more easily discuss
21:31:17 <johnthetubaguy> jogo: we do need care, get too picky and we block the good stuff, I agree
21:31:26 <mikal> True
21:31:33 <dansmith> I also think that we're reflecting code review likelihood through spec review reality, which is better than approving something and never reviewing the code out of lack of interest
21:31:41 <jogo> hmm we did approve 24 so far
21:31:49 <jogo> so I may be wrong about this
21:32:03 <leifz> sorry, yesterday's fetch plus my submission.
21:32:05 <mikal> It will be interesting to see if this means we have a higher hit rate with bp implementations actually merging
21:32:06 <johnthetubaguy> yeah, I been surprised, it feels slow, but we don't seem too bad so far.
21:32:29 <jogo> mikal: yeah
21:32:36 <leifz> jogo: I share your concern.
21:32:39 <mikal> So, a lot are under discussion next week as well
21:32:45 <jogo> so I we have sped up the rate of approval a bit
21:32:49 <jogo> since I last looked
21:32:50 <mikal> So let's not panic yet, just be conscious it is a lot more work for proposers
21:32:54 <johnthetubaguy> its not like I am doing too much other than spec reviews these days, or it feels that way, but we need to make sure it increases "good" productivity, which it looks like it could
21:33:10 <johnthetubaguy> yeah, I kinda think everyone is hitting the template learning curve at once
21:33:16 <leifz> I'd also be curious to track the amount of devops feedback we get.
21:33:17 <johnthetubaguy> which will hopefully get better too
21:33:18 <mikal> I certainly think it will drive better test coverage and more thought on operational impact
21:33:22 <johnthetubaguy> (reviews and writers)
21:33:28 <johnthetubaguy> mikal: +1
21:33:38 <jogo> so I guess my main concern is: we need more eyes on the BPs
21:33:39 <mikal> leifz: HP and Rackspace both have people actively looking
21:33:42 <johnthetubaguy> I like how open the review process is now
21:33:47 <mikal> leifz: I'd like to see a more diverse set of ops though
21:33:50 <jogo> to help keep the review queue moving
21:33:52 <annegentle> from a docs team perspective it's hard to keep up :) But we need to be.
21:34:05 <yjiang5> jogo: possible the spec should have higher review priority than code review?
21:34:25 <leifz> mikal: people are looking, but how is that translating for coverage?
21:34:40 <mikal> leifz: define coverage in this context?
21:35:09 <leifz> mikal: if main purpose is to get feedback early on, it would be good to see that across the board.
21:35:20 <leifz> mikal: if that is happening great, but hard to tell from my perspective.
21:35:26 <mikal> So, people are definitely getting feedback, that's why it feels slow
21:35:33 <mikal> If we were rubber stamping, everything would be approved
21:35:46 <mikal> We're getting more ops feedback, but not as much a I'd like
21:35:47 * jaypipes agrees with dansmith that fewer approved blueprint specs is actually a good thing...
21:35:59 <devoid> There may also be a context issue here. I feel like a lot of the spec reviews are for nits, but few are for overall concept criticism.
21:36:31 <dansmith> the nits are important since they're effectively docs,
21:36:35 <jogo> anyway looks https://review.openstack.org/#/q/is:open+project:openstack/nova-specs++label:Code-Review%253D0,p,002ccc2900015196
21:36:37 <devoid> Which is ok because you are trying to be positive. But bad because then you get to patch set 10 before the real critics come out.
21:36:40 <jogo> BPs without any reviews
21:36:44 <dansmith> but I don't think I see people holding back on criticizing the actual content when appropriate
21:37:17 <dansmith> devoid: if I get to a spec that is nearly unreadable because of formatting and spelling errors, I'm inclined to ask for it to be cleaned up before I try to grok it
21:37:18 <sdague> devoid: any idea if that's across the board, or for things that people already were generally agreed on, and they are just coming to this process the first time?
21:37:18 * jaypipes has been trying to keep up with reviews on nova-specs... but they do take a significant chunks of time.
21:37:20 <dansmith> and I think that's reasonable
21:37:38 <jogo> better link: https://review.openstack.org/#/q/is:open+project:openstack/nova-specs++label:Code-Review%253D0++label:Workflow%253D0,n,z'
21:37:41 <jogo> better link: https://review.openstack.org/#/q/is:open+project:openstack/nova-specs++label:Code-Review%253D0++label:Workflow%253D0,n,z
21:37:49 <johnthetubaguy> jaypipes: +1
21:37:51 <devoid> sdauge: I'm not completely plugged into nova dev so I can't say.
21:38:07 <mikal> Ok, so this is new. I agree we're not keeping up with specs reviews perfectly, but its also not really terrible.
21:38:09 <devoid> dansmith: I agree.
21:38:19 <mikal> So, I think this is mostly a "don't forget to take a look at specs"
21:38:23 <johnthetubaguy> just wanted to confirm... we are approving specs, but then not approving the blueprint till we actually see code go up, at least thats what I am telling people
21:38:27 <jogo> mikal: yup
21:38:33 <dansmith> johnthetubaguy: yeah
21:38:40 <dansmith> johnthetubaguy: important distinction :)
21:38:54 <johnthetubaguy> dansmith: yeah, it seems to be working well
21:39:03 <johnthetubaguy> so far
21:39:07 <mikal> I feel like we should move on unless there's anything else urgent here
21:39:16 <jaypipes> mikal: just a suggestion, but perhaps we relax the defacto policy of discouraging folks from asking for reviews on the ML -- but only for nova-specs?
21:39:24 <johnthetubaguy> mikal: +1 just wanted to make sure people could vent :)
21:39:29 <sdague> jogo: even better link - https://review.openstack.org/#/q/is:open+project:openstack/nova-specs++label:Code-Review%253D0%252Cself+label:Workflow%253D0,n,z
21:39:37 <dansmith> jaypipes: why?
21:39:48 <mikal> jaypipes: what about an etherpad people could highlight things to review in?
21:39:49 <dansmith> jaypipes: no -1 votes means "please look at my spec" .. why do we need email spam?
21:39:58 <mikal> jaypipes: less noise on list, but people feel like they're on people's radars
21:40:25 <devoid> jaypipes, but how are you supposed to get feedback on your spec?
21:40:28 <jaypipes> dansmith: just thinking that if we want to encourage operators to weigh in, their natural instinct isn't to follow a Gerrit view.
21:40:39 <mikal> Oh, I see
21:40:45 <devoid> jaypipes, got it.
21:40:50 <mikal> jaypipes: pointing out interesting specs on the _operators_ list is a good idea
21:41:01 <mikal> jaypipes: although I think we need to be careful about the noise level
21:41:02 <mriedem> jaypipes: mikal: that's why i sent an email to the operators list about some gridlock on my spec
21:41:05 <dansmith> oh, sure, the rule is only for -dev afaik
21:41:06 <johnthetubaguy> yeah, that sounds like a cunning plan
21:41:06 <mikal> mriedem has already done one
21:41:20 <devoid> +1 to pointing out useful specs to operators.
21:41:21 <mikal> Yeah, let's just not send five a day
21:41:32 <jaypipes> mriedem: yeah, for a number of specs I've specifically sent emails to some operators to weigh in...
21:41:38 <mikal> #action remember to send interesting specs to the operators list
21:41:40 <devoid> operators could use more traffic frankly :-)
21:41:58 <sdague> devoid: yeh, the operators list is kind of a quiet corner
21:42:08 <mikal> Ok, let's move on unless you guys want to mutinty really badly
21:42:11 <jaypipes> #action jaypipes make a weekly post to operators list with top 5 or 10 specs for operator input...
21:42:27 <mikal> #topic Open Discussion
21:42:32 <mikal> devoid: you had something for here?
21:42:54 <mriedem> i think devoid had a blueprint item for his sheepdog image backend bp
21:42:57 <devoid> mikal, yes wanted someone to look at my bp
21:43:07 <devoid> https://review.openstack.org/#/c/82584/
21:43:10 <mikal> Ahhh, ok. As in it needs someone to read it?
21:43:15 <devoid> yes plz
21:43:18 <mikal> I'll take a look, but probably not until tomorrow
21:43:31 <mikal> #action Someone needs to take a look at https://review.openstack.org/#/c/82584/
21:43:38 <devoid> also looking for a libvirt dev to help understand the image and disk management code during the summit.
21:43:57 <mikal> I think the dev lounge pod is the way to go there
21:44:14 <devoid> cool
21:44:25 <mriedem> corner padraig if he's there
21:44:33 <mikal> But perhaps we can also find someone who can do some mentoring?
21:44:38 <devoid> i will hold a sign that says "halp, libvirt questions"
21:44:44 <mikal> LOL
21:44:46 <mikal> OMG, yes
21:44:46 <jaypipes> hehe
21:44:53 <mikal> Or a tshirt
21:44:54 <yjiang5> I remember if a patch get no review for a long time, it's ok to asking for review on IRC, but what's acceptable time?
21:45:00 <mikal> I think bribes do work... Just sayin'
21:45:01 <sdague> mikal: moar hoodies
21:45:12 <devoid> mikal, I have openstack troll t-shirts coming. ;-)
21:45:33 <mikal> yjiang5: it might be a good idea to git blame the files you're touching and then see what sort of times those people hang around on IRC?
21:45:51 <mikal> I don't tend to answer pings at 3am for instance, it makes my wife angry
21:46:09 <jaypipes> yjiang5: no definite answer on that... maybe a couple days? also, sometimes it's easier to just approach folks with a specific question about a comment they had on a review to gently nudge someone to take another look at it :)
21:46:10 <yjiang5> mikal: I mean how long after the patch get no review, we can ask for review in the IRC?
21:46:43 <yjiang5> mikal: sorry not clearly expressed.
21:46:43 <mikal> yjiang5: that's hard... if everyone did that for a patch which had been ignored for a few days, we'd flood IRC
21:46:58 <mikal> yjiang5: I think it depends on the severity of the bug being fixed
21:47:08 <jaypipes> mikal: yes, agreed.
21:47:32 <yjiang5> mikal: Just some clean up patch. Not sure it's ok for patch submitted in Jan, 2014.
21:47:54 <mikal> yjiang5: well, there's lots of people around now, so why not drop it in openstack-nova now?
21:48:02 <mikal> yjiang5: i.e. this time of day might be a good time
21:48:09 <yjiang5> mikal: cool, thanks.
21:48:35 <mikal> Anything else? Or do people want 12 minutes of their lives back?
21:48:43 <mriedem> mid cycle meetup
21:48:47 <mriedem> any news there?
21:48:48 <mikal> Oh yes
21:48:50 <mriedem> dates/locations
21:48:57 <mikal> So... I only got the release dates a day ago
21:48:58 <jogo> Hawaii!
21:49:13 <tjones> bora bora
21:49:21 <mikal> I'm going to try and come up with a plan for that tomorrow, because I want to be able to discuss it at the summit
21:49:23 <sdague> yjiang5: also, it's helpful if the bugs these are listed against actually have a priority. I find a lot of the wayward reviews link to a bug in Undefined priority state
21:49:30 <mikal> #action mikal to come up with a mid cycle meetup plan
21:49:36 <oomichi> Hawaii: +1
21:49:39 <yjiang5> sdague: thanks.
21:49:44 <mikal> I'd love Hawaii, but we have no offers to host there
21:49:54 <leifz> I'm up for maui.
21:49:56 <mikal> To set expectations, I think its likely to be mid to late July
21:50:13 <tjones> then how about alaska
21:50:14 <mikal> Almost certainly in the continental US
21:50:29 <tjones> seattle :-)
21:50:35 <mikal> We need to find a good openstack host company in either of those locations
21:50:39 <yjiang5> tjones: +1
21:50:45 <mikal> But yes, I haven't forgotten the mid cycle meetup
21:50:54 <mikal> I've just lacked needed information
21:50:58 <mikal> Anything else?
21:51:01 <dansmith> I think redhat offered raleigh
21:51:13 <mikal> Yeah, there's been about five location offers IIRC
21:51:16 <mriedem> and i'm trying to get an offer for MN
21:51:21 <mikal> We'll need to come up with an equitable method to pick one
21:51:24 <dansmith> I'd be up for MN
21:51:29 <johnthetubaguy> a vote?
21:51:37 <mriedem> new review process
21:51:41 <mriedem> :)
21:51:42 <dansmith> so, one thing,
21:51:42 <jaypipes> tjones: I think alaski would like alaska.
21:51:43 <mikal> Yeah, probably a vote and then a waitlist for people who miss out
21:51:52 <dansmith> UT was annoying because of distance from the airport,
21:52:00 <alaski> jaypipes: +1 :)
21:52:01 <dansmith> so it'd be nice to only consider ones that are reasonably close I think
21:52:05 <tjones> jaypipes: lol
21:52:13 <mriedem> MN would be rochester, but there is an airport
21:52:18 <mikal> dansmith: yeah, with good bandwidth and reasonable hotel pricing
21:52:22 <mriedem> connects from minneapolis
21:52:22 <dansmith> yeah
21:52:24 <mikal> dansmith: so probably not Manhattan
21:52:32 <jaypipes> heh
21:52:33 <dansmith> mriedem: so that means three hops for some people, right?
21:52:34 <mriedem> we have hotels coming out of our ass here with the clinic
21:52:45 <mriedem> dansmith: depends
21:52:49 <mriedem> there are some direct flights
21:52:57 <mikal> mriedem: direct from Canberra?
21:52:58 <mikal> :P
21:53:00 <dansmith> mriedem: if I have to go to SFO, then MSP, then rochester, I'm going to be annoyed
21:53:01 <sdague> mikal: fwiw, montreal actually worked out really nicely for the neutron / qa meeting.
21:53:02 <mriedem> sure..
21:53:14 <tjones> palo alot is right by SFO :-)
21:53:17 <dansmith> montreal would be good
21:53:20 <tjones> s/alot/alto
21:53:28 <mriedem> i'm not sure i'm legally allowed in canada...
21:53:34 <sdague> which isn't continental US, but almost is. And made it simpler for some non US people due to visa issues with US
21:53:34 <mikal> No one has offered a Canadian venue IIRC
21:53:37 <leifz> mikal: give yourself an action to pick a location where dansmith has a nonstop flight.
21:53:39 <dansmith> tjones: burgers in palo alto are what, $15 each?
21:53:41 <beagles> I would suggest St. John's, but people may not want to leave
21:53:49 <mikal> dansmith: hotels are expensive
21:53:50 <beagles> (or be able to)
21:53:58 <dansmith> leifz: nonstop not necessary, but three hops are not in favor :)
21:54:01 <mikal> dansmith: but I do like that area... I used to live there
21:54:04 <tjones> dansmith: depends - you can get even more expensive if you want
21:54:06 <sdague> mikal: when we did it there, it was done on mcgill campus, anteaya has details if you like
21:54:14 <leifz> dansmith: we can't have you grumpy.
21:54:18 <mikal> Ok, so... All points noted. I will come up with a location that makes you all equally unhappy.
21:54:24 <melwitt> haha
21:54:26 <tjones> mikal: awesome!
21:54:27 <dansmith> leifz: I thought you know, I'm never not grumpy
21:54:31 <mikal> Somewhere in New Zealand perhaps
21:54:42 <leifz> dansmith: I do.  I'm talking about the worse grumpy.
21:54:48 <mikal> Stabby grumpy
21:54:50 <dansmith> leifz: oh, fair
21:54:51 <tjones> NZ - that would be great!
21:55:20 <mikal> Ok... So nothing else important right? Just complaining about not having the meetup at Yosemite?
21:55:45 <oomichi> may I ask some feedback about v2.1/v3 API on http://lists.openstack.org/pipermail/openstack-dev/2014-May/034117.html ?
21:56:19 <mikal> oomichi: I think people are waiting for the summit session on that?
21:56:24 <dansmith> yep
21:56:33 <oomichi> ok, I got it:)
21:56:42 <mikal> oomichi: thanks for your patience
21:56:44 <jaypipes> oomichi: actually, the API meeting is in a couple hours...
21:56:51 <tjones> spawn refactor is always happy to have reviews :-)
21:56:53 <jaypipes> oomichi: and it's on the agenda, IIRC
21:57:04 <tjones> (had to sneak that in)
21:57:11 <dansmith> okay, tjones is begging, time to end
21:57:22 <mikal> tjones: yeah, I was looking at the first one of those... 60 revisions!
21:57:31 <tjones> mikal: :-(
21:57:32 <mikal> Ok, meeting done I think
21:57:36 <mikal> #topic Conclusion
21:57:36 <mikal> This is my first time running one of these, so please email me any feedback if you think I can improve…
21:57:39 <mikal> #endmeeting