21:01:29 #startmeeting nova 21:01:30 Meeting started Thu May 30 21:01:29 2013 UTC. The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:33 hello! 21:01:34 The meeting name has been set to 'nova' 21:01:37 who's here? 21:01:43 hi 21:01:46 \o 21:01:46 hi 21:01:48 o/ 21:01:48 hi! 21:01:51 present 21:01:51 #link https://wiki.openstack.org/wiki/Meetings/Nova 21:02:15 o/ and at an OS meetup so may be spotty 21:02:20 o/ 21:02:45 #topic blueprints 21:02:49 so, havana-1 was released today! 21:02:51 #link https://launchpad.net/nova/+milestone/havana-1 21:02:59 16 blueprints and 214 bugs closed 21:03:02 :-) 21:03:20 so now our next milestone is havana-2, with a target of July 18 21:03:21 o/ 21:03:23 #link https://launchpad.net/nova/+milestone/havana-2 21:03:38 so, total 100 havana blueprints right now, 16 in havana-2, and 69 targeted to havana-2 21:03:43 probably optimistic :-) 21:04:05 o/ 21:04:10 but take a look, see what you have on here, make sure it's still current 21:04:18 and if anything is missing, let's get it filed 21:04:36 a lot got pushed from havana-1 to havana-2, so there are a lot already up for review 21:04:52 any particular blueprints anyone wants to dicuss? 21:04:57 or process questions? 21:05:28 crickets 21:05:33 alrighty! 21:05:36 #topic bugs 21:05:45 #link https://wiki.openstack.org/wiki/Nova/BugTriage 21:05:56 I need to re-open that sys_meta not being deleted bug 21:05:57 so, as discussed over the last couple weeks, we've started a slightly modified process for triage 21:05:59 or should I file a new one? 21:06:05 to help distribute the load 21:06:11 (since I reverted the previous fix) 21:06:15 comstud: good question ... re-open i guess? 21:06:20 i thought re-open 21:06:23 * russellb nods 21:06:23 but i dunno :) 21:06:24 ok 21:06:27 yeah, works for me 21:06:46 so if you take a look at the Nova/BugTriage page, we still have some holes in the sign-up list. 21:06:56 could use some more people to take ownership of triage for a given tag 21:07:13 russellb: yeah, what review times 21:07:13 were the numbers you posted accurate in the end? And how do we do a better job? 21:07:48 jog0: yeah, the numbers are pretty accurate now ... current numbers here: http://russellbryant.net/openstack-stats 21:08:07 so if we look at ... http://russellbryant.net/openstack-stats/nova-openreviews.txt 21:08:29 I think we are keeping up overall ... people seem to agree that < 4 days is a very good goal, and we're meeting that 21:08:37 we obviously have some that seem to get neglected and wait much longer 21:09:04 dolphm wrote a nice 'next-review' tool that helps pick a review to do, giving priority based on age, but filtering out stuff you've already looked at and such 21:09:12 so that's worth looking at ... 21:09:15 not sure how this factors into the numbers but I have seen several patches expire with +1s etc 21:09:28 yeah, that's not good 21:09:38 actually, do reviews really expire even with no negative feedback? 21:09:41 that doesn't seem ideal. 21:10:04 the submitter can always revive them so it's not a *huge* deal 21:10:05 yeah, I didn't think they would 21:10:10 https://review.openstack.org/#/c/23207/ 21:10:30 ugh 21:10:44 wow... 21:10:49 not sure if that only happens on stable 21:10:55 i think it happens everywhere 21:11:08 * jog0 just restored teh patch from the dead. 21:11:10 #action need to follow up on whether it makes sense to expire changes with no negative feedback 21:11:24 might explain why the "oldest review" has been stable just under 14 days 21:11:46 IMO that should only happen for reviews with -1/-2 and no updates for X days 21:11:51 so i'll follow up on that ... 21:12:15 there are reviews which are older than that around, just that someone has commented on it in the last 2 weeks. 21:12:18 probably just post to the ML 21:12:38 cyeoh: the script shouldn't reset the timer because of a comment 21:12:44 cyeoh: only if you got a -1/-2 21:12:51 russellb: yea agreed 21:12:52 otherwise it's time since (roughly) when you submitted it 21:13:16 the other tool to use to help pick reviews is reviewday 21:13:29 http://status.openstack.org/reviews/ 21:13:42 that helps prioritize things based on other criteria ... test results, bug/blueprint priority 21:14:02 so basically, using one of these tools instead of going after low hanging fruit will help smooth things out 21:14:06 russellb: can we get that to personalize? 21:14:20 it's all open source :) 21:14:27 but reviewday, not right now 21:14:36 next-review is personalized 21:14:43 based on what you've already commented on and such 21:15:07 https://github.com/dolph/next-review 21:15:26 feel free to hack on it ... i submitted some tweaks today 21:15:37 sounds good, I will redirect my rantings to the ML as this isn't nova only 21:15:47 k :-) 21:15:52 but yeah, i'm all for improvement in this area 21:15:58 i ended up going on quite the stats kick this week ... 21:16:07 I think it would help if we made a concious effort to do extra review effort about 2 weeks out from H2. To help reduce the last minute rush 21:16:08 because it was killing me not having good data on how well we were keeping up with reviews 21:16:19 cyeoh: +1 21:16:48 with all that said ... the review burden for nova vs other projects is *considerably* higher, so kudos for at least doing as well as we have :) 21:17:04 but more to do ... 21:17:12 alright, let's jump to subteam reports 21:17:15 #topic sub-team reports 21:17:27 who's here to give a report? raise hand and i'll call on you to go 21:17:29 db 21:17:34 scheduler 21:17:41 baremetal 21:17:51 dripton: alright, you're up 21:18:10 db meeting failed to happen today. But we got a bunch of good commits in this week. 21:18:23 boris's db-improve-archving commits all went in 21:18:24 yeah, db-improve-archiving got finished up 21:18:26 taskflow 21:18:27 :) 21:18:36 and Roman and Sergei got some extra tests in 21:18:41 great 21:18:43 that's all 21:19:01 kthx! 21:19:04 n0ano: scheduler! 21:19:27 good discussion on whole host allocation (allocating all of a host to one VM, not bare metal but related a little) 21:19:34 expect to see more on that in the future 21:19:56 cool 21:19:59 no one appeared to talk about host directory service, I'm still curious on what exactly that is 21:20:13 that was pretty much it for this week, as always, check the logs for details. 21:20:24 cool thanks 21:20:31 devananda: baremetal / ironic! 21:20:52 pasting a bunch (i actually prepraed something!) 21:21:00 two open-critical bugs in baremetal, both waiting for reviews: 21:21:00 #link https://bugs.launchpad.net/nova/+bug/1178092 21:21:01 Launchpad bug 1178092 in nova "second boot during baremetal deploy does not configure netboot : will hang unless the machine attempts PXE automatically" [Critical,In progress] 21:21:02 #link https://bugs.launchpad.net/nova/+bug/1180178 21:21:03 Launchpad bug 1180178 in nova "Instance IP addresses are re-used even when previous instance could not be powered off" [Critical,In progress] 21:21:21 Several bugs may be related / consolidated into this one: 21:21:25 #link https://bugs.launchpad.net/nova/+bug/1184445 21:21:25 should target them against havana-2 21:21:28 Launchpad bug 1184445 in tripleo "deploy / delete fragility" [High,Triaged] 21:21:37 k, will target :) 21:22:06 Ironic is continuing to move forward. More folks are welcome, we've been discussing how to better split up the work 21:22:22 and we have an API spec now \o/ 21:22:27 getting reasonable amount of help/participation? 21:22:42 redhat's contributed 2 guys to the API so that is moving well 21:22:58 oh, cool, i should have known that, lol. 21:23:04 and we (HP) are mostly taking the internal bits 21:23:17 there's some work refactoring nova/cinder's glance-client and image manipulation 21:23:20 into oslo 21:23:32 being tracked here 21:23:36 #link https://blueprints.launchpad.net/ironic/+spec/image-tools 21:23:59 that's about it! 21:24:31 cool, sounds like lots of good activity and progress! 21:24:39 harlowja: taskflow! 21:24:43 yo yo! 21:25:03 thanks to devananda 21:25:05 "Taskflow is continuing to move forward. More folks are welcome, we've been discussing how to better split up the work." 21:25:11 :-P 21:25:17 hehe 21:25:37 haha, just continuing onwards, db & distributed backend getting done by a couple rackspace folks, 21:25:48 more testing, stackforge nearly there 21:26:15 figuring out new use-cases in ironic and nova, and seeing how taskflow can help there 21:26:17 *and cinder* 21:26:46 more people getting involved with different backends 21:26:48 so all good 21:27:00 thats about its :) more nova folks always welcome ;) 21:27:01 cool stuff, and meeting is just before this one if anyone is interested 21:27:05 yuppers 21:27:15 annnnnnnnd... hartsocks: vmware! 21:27:27 hey 21:27:33 #link http://eavesdrop.openstack.org/meetings/vmwareapi/2013/vmwareapi.2013-05-29-17.01.html 21:27:43 So we've got 2 blueprints targeted for H-2 21:28:10 And we have about 4 "critical" bugs/patches we did not make for H1 that will get pushed to H2 now. 21:28:39 btw, on reviews on that driver ... 21:28:40 We're also getting more blueprints in from other folks out side of the regular crowd. 21:28:54 i mostly don't touch it if i see you haven't touched it yet 21:29:03 would like to see your +1 first 21:29:08 Thanks. 21:29:17 I am humbled by your trust 21:29:17 if there's others I should consider the "maintainer" like that, let me know 21:29:24 * hartsocks bows 21:29:30 doesn't mean I blindly +2 after that :-p 21:29:39 Good to know. :-) 21:29:47 just saying there was at least one waiting over a week, but i hadn't reviewed because i was hoping you would first 21:30:08 I will try and cycle through the reviews faster. 21:30:31 all good ... just letting you know how i think, i guess 21:30:42 and the one i was thinking about you have reviewed already now 21:31:13 I've also worked through the bug lists and prioritized most stuff. 21:31:18 target bugs to havana-2 if you want to try to get them in 21:31:23 awesome, much appreciated 21:31:49 So, VMware stuff is starting to pick up steam here. 21:32:15 I should have a few new developers coming on line in the next few weeks from our VMware team too. (just BTW) 21:32:24 cool, good to hear 21:32:32 i like maintained code :) 21:32:37 yep. 21:32:41 anything else? 21:32:49 That'll cover it. :-) 21:32:52 thanks! 21:32:57 #topic open discussion 21:33:03 any misc topics? 21:33:15 yep! 21:33:43 I'd like to talk about trying something to make reviewing all the ported v3 API extension changesets about to come through easier 21:34:05 cool, have an idea? 21:34:33 at the moment the changesets look pretty big because although a lot of the code is the same as in V2 its a new file and so the diff looks large 21:35:06 so what I'd like to do for the remaining extensions in contrib (and there are about 60!) is to do a giant copy of paste from contrib to plugins/v3 21:35:30 so how long should we be supporting v2? 21:35:35 the code would essentially be "dead" in there. as neither the v2 nor v3 extension code will attempt to load them 21:35:43 * russellb is thinking about the cost/benefit to any refactoring to cut down on copy/paste 21:35:47 russellb: I guess for at least one full cycle 21:35:59 cyeoh: so one big copy/paste that doesn't work, 21:36:11 cyeoh: then a bunch of small patches with just deltas for v3-ness? 21:36:17 dansmith: yes 21:36:19 and we just "ignore" the big ugly first one? 21:36:20 so ... if we "completed" v3 in havana ... could have it removed in I, ok ... 21:36:32 that's actually pretty clever, heh 21:36:33 cyeoh: that's an interesting appraoch 21:36:35 yep and similarly for the tests too because they have a similar review issue 21:36:45 makes the reviews sound much more pleasant (after that) 21:36:53 though I would feel so so so dirty approving that first one 21:37:04 yea I realise its rather ugly and will probably need some updates when people update the V2 21:37:05 cyeoh: could we try it with a couple of extensions first? 21:37:19 like, get three patches up, the big one, plus two conversions on top of it so we can see? 21:37:29 dansmith: sure 21:37:33 and if that works 21:37:35 I'm +1 for that 21:37:35 could do 1 at a time 21:37:40 so each conversion is just 2 changes 21:37:47 well, 21:37:50 1 copy/paste that isn't used yet ... another that converts it 21:38:00 would help prevent things from getting too out of sync 21:38:00 we could do that too, I guess 21:38:03 yeah 21:38:18 and we rubber stamp the first in each pair, if we approve the second? 21:38:24 I'd be +1 on that approach 21:38:27 and also doesn't leave dead code in the tree for longer than or whatever 21:38:28 yep, I'm happy to do that too. 21:38:40 cool 21:38:47 then I can feel like less of a slackass 21:38:52 :) 21:39:04 I'm just aware that 60 or so reviews in the next 6 weeks is actually adding a reasonable amount of review load so want to make it as easy as possible :-) 21:39:11 same here ... i didn't start looking at v3 patches until it was too late for havana-1 ... sorry 21:39:14 way too many reviews out there 21:39:18 (or so I feel) 21:39:27 cyeoh: much appreciated 21:39:30 heh np. They're starting to flow in now :-) 21:39:32 cyeoh: let's see how it goes on the first couple 21:39:41 and then adjust the approach if needed 21:39:58 it sounds like it'll make it pretty easy to review these 21:40:11 cyeoh: do you have a doc on the high level changes in V3 that dives into the details to? so we know what to look for during a reviwe 21:40:42 jog0: Mauro posted a link to a wiki page a couple of weeks ago. I'll have to go dig it up 21:41:03 https://wiki.openstack.org/wiki/NovaV3API 21:41:04 ? 21:41:09 that's just from google, heh 21:41:40 I found this in ML: https://etherpad.openstack.org/api-v3-review-guide 21:41:49 melwitt: nice 21:42:15 melwitt: yea, thats it. We need to add a few other things. 21:43:04 everything that is intentionally changed (like return codes) should be explicitly stated in the changeset comment, but would also help to have a separate list of things we're meant to consider during the port (like json/xml inconsistencies for example) 21:43:37 cyeoh: ahh 21:43:39 given the number of different blueprints which can apply to the same extension there may be multiple passes though. 21:44:40 cyeoh: random thing ... there is a versions.py in the api code that lists the APIs we're serving up ... v3 isn't in there yet, will need to be added, and have its status set to something that indicates its a WIP 21:45:00 I don't want anyone to consider the v3 API to be in anyway "fixed" until late in the H cycle 21:45:06 yep 21:45:26 so not even making it discoverable (even if marked as WIP) until later probably isn't bad 21:45:27 russellb: yea I have been holding off on the versions stuff because of the discussion around discoverability 21:45:33 is v3 configurable? 21:45:36 as in, can it be disabled? 21:45:42 should do that too if not already 21:45:54 and maybe even have it disabled by default until it's "done" 21:45:58 hrm do you want a config option because you can just remove it from the paste file 21:46:17 yeah, a config option i think ... because ideally we don't want anyone to have to edit the paste files 21:46:19 from /etc/nova/api-past.ini 21:46:23 paste files are more like code than config IMO 21:46:45 glance had (has?) a similar option for the v2 API 21:46:46 ok. I'll add something to disable it by default for now 21:46:50 cool 21:47:39 i *usually* don't like having to develop a "feature" in tree like this ... but this is so massive, don't see any other way 21:47:49 a well justified exception, i think 21:48:15 yea keeping in sync with V2 changes is a bit of work as it is. 21:48:27 * russellb nods 21:48:44 so, we have a plan then? 21:48:48 for now at least? :) 21:48:54 yep, thanks! That's it from me :-) 21:49:34 cool! 21:49:36 anything else? 21:49:51 cyeoh: will you be addressing http://www.mail-archive.com/openstack@lists.launchpad.net/msg23320.html in v3? are those the JSON/XML issues you mentioned? 21:51:21 jog0: that's the kind of thing we need to catch. If you could file a bug report or add an entry to the blueprint for those that you are aware of, that would really help. 21:52:15 cyeoh: I will add an entry in the BP, sadly I am not aware of how often/where this happens 21:52:33 there are a few cases where JSON does one thing and xml does something different too 21:53:03 jog0: yea, ivanzhu is doing a scan to try to pick up as many as possible, but its an easy enough thing to miss 21:53:06 cyeoh: which blueprint would this go under https://blueprints.launchpad.net/nova/+spec/v3-api-inconsistencies ? 21:53:26 jog0: yea, that will do 21:54:28 alright, thanks everyone ... more discussion in #openstack-nova is welcome as always 21:54:37 jog0: cyeoh: let's just continue over there if needed 21:54:39 bye! 21:54:41 #endmeeting