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