21:01:31 <vishy> #startmeeting nova 21:01:32 <openstack> Meeting started Thu Sep 6 21:01:31 2012 UTC. The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:34 <openstack> The meeting name has been set to 'nova' 21:01:50 * dansmith wonders what the Star Meeting is 21:02:04 <ttx> o/ 21:02:17 <markmc> yo 21:02:43 <russellb> HI 21:02:48 <dprince> hello 21:02:54 <vishy> #topic bug triage 21:03:07 <vishy> I have not been on top of this. 21:03:10 <ttx> 66 untriaged today 21:03:13 * vishy has been finding new bugs 21:03:29 * markmc didn't get to do his 20 this week yet 21:03:35 <markmc> 66 21:03:37 <markmc> that's depressing 21:03:39 * ttx hasn't found time eiher. Crazy elections 21:04:07 <markmc> we had it down below 40 last week AFAIR 21:04:14 <ttx> should do a few tomorrow 21:04:27 <vishy> its like digging a hole in the ocean 21:05:26 <ttx> I don't see any other way of checking we didn't overlook something, though... 21:05:31 <vishy> agreed 21:05:36 <ttx> at least some casual check 21:05:41 <vishy> i guess we just keep plugging away 21:05:42 <ttx> no need to reproduce them 21:06:01 <ttx> most of the time you can feel if they look genuine 21:06:13 <jk0> o/ 21:06:22 <vishy> lets try to just do a first pass and get them down to 0 21:06:32 <vishy> looking for critical ones 21:06:32 <markmc> yeah, being able to "casually triage" is a skill you acquire over time 21:06:40 <markmc> when you get started triaging, you tend to over-triage 21:07:02 <ttx> better casually triaged than completely unseen 21:07:06 <markmc> yep 21:07:12 <dansmith> are you instructing us to do things half-assed? 21:07:17 <dansmith> I thought I'd never see the day! 21:07:26 * russellb tends to try to reproduce, or at least read code to verify bug is there and spends too much time on each one 21:07:26 <ttx> the goal here is to catch the overlooked kitten killer 21:07:29 <dansmith> I'm really good at half-assing things 21:07:41 * vishy elects dansmith 21:07:46 <dansmith> hah 21:07:48 <vishy> professional half-asser 21:07:51 <russellb> congrats 21:07:59 <ttx> dansmith: cheers 21:08:00 * dansmith runs off to change his job title on linkedin 21:08:08 <russellb> .#note dansmith is now the official professional half-asser 21:08:13 <dansmith> hah 21:08:23 <vishy> ok so everyone try to go through at least five bugs and mark critical ones for folsom 21:08:36 <russellb> i'll take your 5 and do 10! 21:08:36 <dansmith> just so I'm clear, 21:08:51 <dansmith> I don't think that non-core folks can mark things in terms of importance, can we? 21:08:55 <ttx> just set the milestone to folsom-rc1 for those you think should be on release radar 21:08:59 <russellb> yes you can 21:09:04 <dansmith> I think I can confirm/incomplete them, but that's it... 21:09:06 <ttx> dansmith: just join ~nova-bugs 21:09:07 <dansmith> oh, hmm, okay 21:09:08 <dansmith> oh 21:09:16 <ttx> open team 21:09:18 <russellb> open team 21:09:25 <vishy> #topic RC1 buglist 21:09:43 <ttx> russellb: I wonder how much longer it wil take people to realize we are the same person 21:09:57 <russellb> ttx: not long if you bring it up in a meeting like that 21:10:01 <vishy> #link https://launchpad.net/nova/+milestone/folsom-rc1 21:10:26 * vishy wonders why ttx/russellb is talking to himself 21:10:51 <markmc> russell's french accent gives him away every time 21:11:02 <russellb> so a few on the rc list unassigned 21:11:06 <ttx> vishy: 2 unassigned 21:11:19 <ttx> err. 3 actually 21:11:36 <ttx> bug 1042215 21:11:36 <uvirtbot> Launchpad bug 1042215 in nova "Add unit testing coverage for nova.volume.cinder.API" [High,Confirmed] https://launchpad.net/bugs/1042215 21:11:43 <ttx> which should be "wishlist" imho 21:11:59 <russellb> yeah. 21:12:02 <vishy> just looking through those 21:12:03 <ttx> (folsom-rc1-targeted, but wishlist) 21:12:15 * ttx sets to wishlist 21:12:24 <vishy> the other two look pretty simple 21:12:40 <vishy> anyone want to volunteer? 21:13:07 <russellb> i'll take one 21:13:13 <jog0> vishy: I can take 1042539 21:13:15 <russellb> um ... flavorid one i suppose 21:13:25 <eglynn> vishy I'll grab the other tmrw 21:13:37 <vishy> cool 21:13:47 * jog0 hand the bug to russellb 21:13:51 <ttx> assign yourselves directly 21:13:54 <vishy> aye 21:13:56 <russellb> jog0: heh, ok. 21:14:16 <vishy> #topic outstanding reviews 21:14:21 <ttx> vishy: on the critical list, the most scary is bug 1040956 21:14:23 <uvirtbot> Launchpad bug 1040956 in nova ""Unable to get quota information" in horizon when using quantum" [Critical,Confirmed] https://launchpad.net/bugs/1040956 21:15:02 <ttx> the others sound under control, i.e. a course of action is defined 21:15:22 <markmc> ttx, unclear if bug 1040956 has a nova aspect at this point 21:15:24 <uvirtbot> Launchpad bug 1040956 in nova ""Unable to get quota information" in horizon when using quantum" [Critical,Confirmed] https://launchpad.net/bugs/1040956 21:15:41 <ttx> markmc: right, my point exactly 21:15:48 <markmc> ttx, needs at least a plan spelled out in the bug 21:16:11 <ttx> or being abandoned/deferred 21:16:17 <vishy> the proxy solution is the right one 21:16:25 <vishy> but it is too late to get that in 21:16:47 <markmc> 53 reviews outstanding 21:16:51 <ttx> vishy: how much critical is this ? Could it be considered a known gap ? 21:17:04 <vishy> the fix to have it return none seems like it could be done to stop the error at least 21:17:04 <russellb> markmc: seems to hover around 50 21:17:21 <markmc> russellb, despite everyone's best efforts :/ 21:17:32 <russellb> well some amount is normal, things in progress 21:17:43 <markmc> 12436 is for one of the targeted bugs 21:17:45 <russellb> we should define what "keeping up" means, and track against that, because it's not 0 open reviews 21:17:55 <markmc> https://review.openstack.org/12436 21:18:03 <ttx> vishy: maybe just make sure the plan is defined, and the assignee still on track to implement that plan 21:18:04 <vishy> i think we are doing pretty well with reviews 21:18:15 <vishy> this one I would like some other opinions on: https://review.openstack.org/#/c/11923/ 21:18:18 <ttx> (on 1040956) 21:19:01 <russellb> yikes, looks invasive for this late in the game 21:19:17 <markmc> yeah, was about to call that out too 21:19:18 <russellb> (libvirt network one) 21:19:21 <markmc> bug is targeted 21:19:41 <ttx> vishy: is the folsom-rc1 buglist complete as far as triaged bugs go ? Only missing potential blockers from the untriaged list ? 21:19:55 <jog0> I have one I waiting on: https://review.openstack.org/#/c/12231/ 21:19:55 <dansmith> ttx: when triaging, are we to target legit bugs to folsom? not sure I should be making that determination :D 21:20:01 <dprince> I've got one coming for Nova volumes (which we just broke 4 hours ago) 21:20:16 <vishy> dansmith: default to target it if it looks important 21:20:28 <dansmith> vishy: okay 21:20:32 <vishy> dprince: :( k 21:20:38 <vishy> dprince: how did we break it? 21:20:50 <ttx> dansmith: folsom-rc1 targeting is just a simple way to bring the bug to release radar 21:20:52 <dprince> merged in some iscsi driver stuff from Cinder. 21:21:15 <dansmith> ttx: okay, just seems like too much responsibilty for someone like myself :P 21:21:19 <ttx> dansmith: we can remove the milestone target if it's abusive 21:21:32 <markmc> iscsi stuff is getting worrying 21:21:43 <vishy> oh that is the one that I wanted to discuss 21:21:54 <vishy> i will save it for its own topic though 21:22:15 <ttx> vishy: is the folsom-rc1 buglist complete as far as triaged bugs go ? Only missing potential blockers from the untriaged list ? 21:22:35 <vishy> ttx: afaik 21:22:43 <ttx> ok 21:22:50 <vishy> ttx: can you use your launchpad foo to get a list of in progress bugs that are not targetted 21:23:00 <vishy> to see if some haven't been targetted yet? 21:23:18 <vishy> #topic Tempest gating 21:23:30 <ttx> vishy: htat will require a launchpadlib script that I won't be able to produce until some sleep is poured into me 21:23:34 <vishy> i'm not sure what this topic is 21:23:35 <dansmith> I added this one on behalf of the qa folks 21:23:47 <vishy> ttx: no worries, I was hoping that search options might make it 21:23:53 <vishy> dansmith: ok go 21:24:11 <dansmith> so, there's a thread going on on the qa-team list 21:24:13 <ttx> vishy: also do we really want to target all inprogress bugs ? They will end up on the RC1 is they merge, and not if not 21:24:25 <dansmith> about the asymmetric nature of the gating into tempest and other projects like nova 21:24:32 <vishy> ttx: no I was just curious for the list to see if any should be targetted 21:24:44 <dansmith> nova can check stuff in all day long as long as it passes the smoke tests, but may (and does often) break tempest, 21:24:52 <dansmith> which prevents further stuff from going into tempest until it's resolved 21:25:05 <dansmith> usually the way that happens is by adding a commit in front of somethign to skip the newly-broken test 21:25:20 <dansmith> since tempest is not run against every commit in nova, it makes it real hard to figure out which commit broke something 21:25:28 <dansmith> as it is usually days later before the breakage is noticed in tempest 21:25:35 <dansmith> the suggestions have been: 21:25:39 <ttx> vishy: you can search for in progress bugs and see which ones don't have the watch icon that denotes milestone targeted 21:26:01 <dansmith> 1. Add a non-gating run of tempest for every nova commit, and ask the nova core folks to try to keep an eye on things when that non-voting test fails 21:26:01 <vishy> dansmith: how about a non-voting tempest test 21:26:16 <dansmith> 2. Make it voting, which will delay nova gate quite a bit 21:26:28 <vishy> my vote would be start non-voting 21:26:35 <dansmith> vishy: that's one option, although I think social behavior will route around that fairly quickly because tempest is already a bit flaky, 21:26:38 <russellb> +1 to non-voting on every commit 21:26:39 <dansmith> and folks will start to ignore it 21:26:52 <dansmith> I think that long-term, 21:26:55 <russellb> i would always look personally ... doesn't take long to scan to see which test it was 21:27:00 <ttx> vishy: there are 101 of them 21:27:03 <russellb> and see if it was a test that looks related to what the change was 21:27:16 <russellb> ttx: but only 53 reviews, heh. 21:27:18 <dansmith> they're looking for some support from nova-core on a voting run, once some performance (i.e. parallel runnage) issues can be addressed in tempest 21:27:41 <russellb> I think we should have it non-voting for a while to gain the support for a voting run 21:27:42 <dansmith> russellb: if nova-core can/will do that reliably, then I think that will go a long way 21:27:43 <ttx> russellb: some people being overly optimistic.. and abandoned reviews. 21:27:49 <vishy> russellb: agreed 21:28:03 <markmc> any tempest test which isn't gating becomes something qa folks will always need to chase 21:28:10 <markmc> but the gate can't take a silly amount of time 21:28:24 <russellb> how long does a full tempest run take now? 21:28:34 <dansmith> jaypipes and I think that long term, it really needs to be symmetric 21:28:50 <markmc> right, doesn't seem right for tempest to gate on the full set of tests 21:29:02 <dansmith> depends on the machine, but I think it runs in a little less than 45 minutes on my VM 21:29:08 <dansmith> which is obviously a huge problem for nova's gate 21:29:18 <dansmith> there's work identified to try to mitigate that 21:29:21 <dansmith> markmc: exactly, 21:29:42 <dansmith> markmc: it means that tempest is always broken and folks are discouraged from contributing because you always have to clean up someone else's mess first 21:29:43 <eglynn> aren't a subset of the tempest tests annotated as smoke tests? 21:29:45 <dansmith> believe me, I know :) 21:29:50 <russellb> yeah ... if it ran in the early jenkins check run, it would probably finish before it's approved 21:29:54 <dansmith> eglynn: yes, that's the gate now, and it's wayyyyy small 21:29:59 <markmc> how about we (nova) decide what's an acceptable length of time for the gate? 21:30:12 <dansmith> russellb: well, if that is run async to the check, but I'm not sure if that's the plan or not 21:30:14 <russellb> markmc: 2 minutes! 21:30:19 <markmc> tempest folks can make as many tests gating as they want, so long as it comes under that 21:30:33 <markmc> everything else winds up something they have to chase 21:30:45 <dansmith> markmc: that certainly sets a goal to achieve :) 21:30:58 <markmc> non-voting thing sounds reasonable way to get some help chasing, but will probably have limited success 21:31:23 <dansmith> markmc: right, I can ignore stuff all day long if it doesn't block me.. it's part of my half-assed job :) 21:31:59 <dansmith> if nova-core is diligent about it, then it becomes non-blocking for the flaky cases, while still helping towards the end goal 21:32:17 <vishy> so sounds like we are agreed 21:32:28 <vishy> non-gating test at first 21:32:38 <vishy> then gating added later 21:32:46 * ttx vanishes 21:32:48 <russellb> at least up to a sane amount of time 21:32:50 <vishy> nova core will look for breakages 21:33:09 <dansmith> so you're in support of eventually shooting for a full gate as long as some reasonable attempt to speed it up is made? 21:33:16 <dansmith> I think that will work for everyone 21:33:26 <russellb> works for me 21:33:30 <dansmith> cool 21:33:35 <markmc> dansmith, what gets in gate now? type='smoke'? 21:33:44 <dansmith> markmc: yep 21:33:55 <markmc> dansmith, so, it's totally up to you guys what gates and what doesn't 21:34:04 <markmc> dansmith, we'll just moan if we notice it's taking too long 21:34:20 <vishy> #topic XML support and sample testing 21:34:36 <dansmith> markmc: heh, well, that's one way to look at it ;) 21:34:46 <vishy> so lots of progress here 21:35:03 <vishy> we have all the core apis covered now except that servers needs to be expanded a bit 21:35:23 <vishy> I think it is optomistic to think we will cover all of the extensions 21:35:37 <vishy> but I think we can cover the most important ones 21:35:56 <vishy> and get the rest in early grizzly 21:36:05 <markmc> cool stuff 21:36:18 <markmc> vishy, small thing, approve the samples move to docs https://review.openstack.org/#/c/12246/ 21:36:29 <dansmith> vishy: do you want to prioritize those? 21:36:34 <dansmith> if so, we'll pick from the list in order 21:36:53 <vishy> dansmith: Yeah i was hoping to go through them 21:37:13 <vishy> i think top priority is expanding servers tests to add the other list and posts 21:37:19 <vishy> and actions 21:37:33 <vishy> then i will try to go through the list of extensions and come up with which are most important 21:37:53 <dansmith> vishy: okay, I did the start/stop action extension already, 21:37:57 <dansmith> so I can look at the core ones too 21:38:04 <vishy> dansmith: cool 21:38:15 <vishy> dansmith: I would split the servers tests into two groups 21:38:19 <vishy> or maybe three 21:38:33 <vishy> I don't think we need to run the all_extensions tests for all of the servers tests 21:39:09 <vishy> other than that, I hopefully will have time to do a couple more 21:39:31 <vishy> #topic Removing Compute/Scheduler 1.x RPC APIs 21:39:36 <vishy> not sure who added this one 21:39:49 <maurosr_> I can help too 21:39:51 <russellb> that was from last week 21:40:14 <markmc> vishy, leftovers from last week? 21:40:15 <markmc> it's in now 21:40:18 <russellb> markmc: did all of those changes make it in? 21:40:22 <markmc> yeah 21:40:25 <russellb> settled! :) 21:40:28 <vishy> woo! 21:40:35 <vishy> additional bonus topic then 21:40:44 <vishy> #topic syncing from cinder to nova-volumes 21:40:55 <markmc> and the other way around 21:40:58 <vishy> I wanted to run my thoughts on this by you guys 21:41:06 <markmc> i.e. sync volumes stuff from cinder into nova 21:41:17 <markmc> but there's a tonne of core stuff that could be synced from nova to cinder 21:41:26 <markmc> e.g. removing old scheduler RPC API versions 21:41:40 <vishy> markmc: good point 21:41:45 <markmc> oh, wait 21:41:47 <vishy> so my thought was to do a sync a ll at once 21:41:53 <markmc> cinder scheduler rpcapi is still at 1.0 :) 21:42:01 <vishy> markmc: :) 21:42:12 <jgriffith> vishy: +1 on all at once 21:42:15 <russellb> 1.0 is the old and busted! 21:42:19 <vishy> so at rc-1 just do a massive patch with all of the differences 21:42:35 <vishy> (hopefully not that massive) 21:42:40 <markmc> massive patch == not reviewed closely == risky 21:42:45 <jgriffith> vishy: As of the other day it's not that large 21:42:52 <jgriffith> vishy: At least in terms of volume specific 21:42:54 <vishy> or else our grizzly security fixes are going to be troublesome 21:43:32 <markmc> yeah, what needs to be synced into nova probably isn't huge 21:43:49 * markmc has no idea what it's like the other way 21:44:01 <jgriffith> markmc: not pretty 21:44:44 <jgriffith> markmc: but I don't see that as being as critical either 21:45:01 <jgriffith> markmc: ie non-volume/common 21:45:15 <markmc> jgriffith, only critical for bug fixes 21:45:30 <vishy> yeah it will make bug fixing harder 21:45:40 <markmc> jgriffith, not syncing cleanups/refactoring is just a question of making maintenance burden bigger over time 21:45:59 <jgriffith> understood 21:46:39 <dprince> jgriffith: on a related note. If you buy this for Cinder I'm gonna push one to Nova too: https://review.openstack.org/#/c/12517/ 21:47:06 <jgriffith> markmc: yes, was just waiting for the second update 21:47:09 <dprince> jgriffith: after that I need to look into one more Nova Smoke Test failure with the recent Cinder syncing. 21:47:31 * dprince sorry to interrupt guys 21:48:46 <russellb> I suppose a good summit session (or sessions?) could be determining what we can factor out of nova and cinder to remove as much of the duplication of core code as possible. 21:49:04 <russellb> so that this isn't a long term problem ... 21:49:24 <dprince> russellb: long term Nova volumes goes away right? 21:49:36 <russellb> yes 21:49:37 <vishy> nova volumes is gone for grizzly 21:49:55 <russellb> isn't there some other duplication though? 21:49:56 <vishy> but we may leave the code in for backporting patches 21:50:05 <jgriffith> I think russellb is referring to the other common pieces 21:50:33 <russellb> yeah. 21:50:50 <markmc> dprince, e.g. cinder has a scheduler 21:51:31 <markmc> vishy, you mean, not delete the code in grizzly? 21:51:42 <dprince> SUre. But its schedulers are a bit more simplistic than Nova's right? 21:52:11 <markmc> dprince, yes, but there's still copied-and-pasted code ... which is what openstack-common is trying to clean up 21:53:10 * dprince buys it 21:53:25 <vishy> markmc: I mean not delete the code until the end of grizzly 21:53:48 <markmc> vishy, I don't think that will help stable branch, really - but we can discuss later 21:53:57 <vishy> markmc: although we could just have people propose directly into stable/folsom and just make sure that it is in cinder first 21:54:03 <markmc> vishy, right 21:54:43 <dprince> vishy: That is what I'm doing (Cinder first then Nova). Makes sense. 21:55:13 <markmc> vishy, none of the reasons for "must be in nova master before stable/folsom" applies where the code in master is to be removed 21:55:20 <vishy> gotcha 21:55:23 <vishy> k nm then 21:55:28 <markmc> cool 21:55:34 <markmc> thanks for thinking of stable tho :) 21:55:48 <vishy> so the sync of code from cinder -> nova-volumes 21:55:55 <vishy> how do we do that piece? 21:56:59 <markmc> ok, how about I do a rough analysis and send out a mail 21:57:04 <markmc> see what commits we're missing etc. 21:57:14 <markmc> might just do the syncing myself, we'll see 21:57:25 <jgriffith> I've been doing diffs on nova/volume and cinder/volume... that part isn't so bad 21:57:34 <jgriffith> Was planning one big patch to sync next week (from me) 21:57:47 * markmc would prefer to avoid "one big patch" 21:57:58 <markmc> harder to do a real review 21:58:13 <jgriffith> For that portion it's not as large, but I'll leave it to you 21:58:27 <jgriffith> Most of the stuff we've been telling people to submit in both anyway 21:58:53 <markmc> jgriffith, ok, I'll sync with you tomorrow when I've had a look 21:58:56 <vishy> markmc: ok thanks 21:59:02 <vishy> #topic Open Discussion 21:59:10 <vishy> anything else? 21:59:14 <mtreinish> One quick thing, I've got three reviews just waiting on approval: https://review.openstack.org/12198 https://review.openstack.org/12355 and https://review.openstack.org/12359 21:59:27 <mtreinish> I'd like to get them pushed through to close out the xml metadata bug: bug 1040891 21:59:28 <uvirtbot> Launchpad bug 1040891 in nova "XML formatting for volume metadata incorrect" [High,In progress] https://launchpad.net/bugs/1040891 22:00:38 <vishy> just sent in https://review.openstack.org/#/c/12198/ 22:00:46 <vishy> i had already reviewed but forgot to click the button 22:01:12 <jog0> I ahve a nova client bug: https://review.openstack.org/#/c/12069/ 22:01:12 <vishy> https://review.openstack.org/#/c/12355/ that one needs someone else to look at though 22:01:34 <mtreinish> vishy: cool, thanks 22:01:43 <jk0> I always review and not realized I'm not logged in, the go to click the review button but instead the diff one and get bombed with windows 22:01:46 <jk0> good times 22:01:47 <vishy> jog0: approved, pretty obvious 22:02:17 <jog0> vishy: and this nova one, which is less obvious: https://review.openstack.org/#/c/12231/ 22:02:25 <jog0> vishy: thanks 22:06:45 <jk0> /c/ 22:06:48 <jk0> anything else? 22:09:40 <russellb> vishy: #endmeeting ? 22:09:53 <vishy> #endmeeting nova