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