21:03:33 <vishy> #startmeeting nova 21:03:33 <openstack> Meeting started Thu Aug 30 21:03:33 2012 UTC. The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:03:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:03:35 <openstack> The meeting name has been set to 'nova' 21:03:37 <russellb> ah ok, sorry for the distraction jgriffith 21:03:45 <jgriffith> There was a problem last week when mtaylor made some changes 21:03:49 <jgriffith> might be a hold over from that 21:03:58 <vishy> #link http://wiki.openstack.org/Meetings/Nova 21:04:30 <vishy> who all is here? 21:04:37 <dansmith> thou 21:04:38 * russellb raises hand 21:04:40 <markmc> yo dawg 21:04:43 <nati_ueno> hi 21:04:47 <maurosr_> Me 21:04:59 <markmc> very disorderly rollcall vishy 21:05:04 <jk0> o/ 21:05:07 <markmc> what kind of a clown show are you running here? 21:05:26 <dprince> hi 21:05:28 <russellb> absolute shit job of a roll call i'd say 21:05:42 <vishy> #topic Api Sample Testing 21:05:47 <markmc> russellb, heh 21:05:50 <vishy> :) 21:06:11 <vishy> ok so I've been working on the api sample testing and I've come across a couple of non-spec issues in limits 21:06:18 <vishy> * in flavors 21:06:19 <vishy> that is 21:06:43 <vishy> one of them I have fixed: https://review.openstack.org/#/c/12165/ 21:06:44 <markmc> non-spec means implementation doesn't match the spec? 21:06:49 <vishy> markmc: correct 21:06:55 <dansmith> so change the spec, duh! :) 21:07:05 <vishy> there are two extra fields in our current flavors implementation 21:07:10 <vishy> rxtx_factor and swap 21:07:20 <vishy> so officially those should both be extensions 21:07:27 <vishy> we have three options: 21:07:30 <vishy> 1) edit the spec 21:07:35 <vishy> 2) ignore them 21:07:43 <vishy> 3) add extensions for them 21:07:51 <markmc> have they been around forever? 21:07:52 <vishy> thoughts/preferences 21:07:57 <vishy> markmc: pretty much 21:08:05 <markmc> then they're part of the API IMHO 21:08:10 <dansmith> I don't know how, but I can sign myself (or us) up for #3 if you decide 21:08:21 <vishy> the other odd bit is that they aren't properly namespaced like ephemeral and is_public 21:08:39 <markmc> I guess if the extension was enabled by default, and we weren't changing their naming or behviour 21:08:42 <markmc> that would be fine 21:08:43 <vishy> the extensions are pretty easy to make, I just did one above. 21:09:10 <vishy> clearly changing behavior is not an option 21:09:18 <vishy> so add extensions? 21:09:33 <markmc> sounds sensible IMHO 21:09:51 <dprince> Seems like a potentially breaking change thought right? 21:10:12 <dprince> If they are going to have extensions namespace prefixes that is. 21:10:20 <markmc> dprince, only if a provider chooses to disable the extension 21:10:32 <markmc> dprince, oh, I thought vishy mean they wouldn't be namespaced 21:10:56 <vishy> they will have to be added without namespaces 21:11:05 <vishy> I'm not sure what that means for xml but oh well 21:11:13 <dansmith> screw xml! 21:11:22 <markmc> so, really it's just a way for providers to choose to disable them 21:11:27 <markmc> no API change by default 21:11:55 <dprince> If it doesn't change the behaviour I think this is just an impl decision then. I'm for moving them to extensions then. 21:12:20 <vishy> markmc: right, the purpose of this is I want our output to match the spec 21:12:42 <vishy> and not have a bunch of hidden non-spec options that happen to exist but aren't documented 21:12:59 <markmc> vishy, our output matching the spec if all extensions are disabled, right? 21:13:02 <markmc> sounds sane to me 21:13:13 <jk0> +1 21:13:32 <dprince> vishy: So essentially the 'all_extensions' output would remain the same (what we see today) but the core API samples would be pure to the API spec. 21:13:34 <vishy> markmc: correct 21:13:40 <vishy> dprince: right 21:13:46 * dansmith kneels to be #action'd 21:13:47 <dprince> do it 21:13:51 <vishy> ok I'm cool with that 21:14:02 <vishy> dansmith: might be easiest for me to write these as I just wrote one 21:14:14 <dansmith> vishy: heh, fine, fine :) 21:14:17 <markmc> dansmith, on your feet, man! 21:14:18 <vishy> ok next thing is I am going to need review help 21:14:30 <dansmith> markmc: heh 21:14:33 <vishy> I'm producing these but there will be a lot of them 21:14:35 <markmc> vishy, I'll jump on your reviews in the morn 21:14:43 <vishy> markmc: cool 21:14:50 * markmc counts 5 so far? 21:14:52 <vishy> lastly I could still use implementation help 21:15:00 <vishy> http://etherpad.openstack.org/api-samples 21:15:09 <vishy> i put some docs in for how to get started 21:15:13 <vishy> on that etherpad 21:15:18 <dansmith> vishy: maurosr_ is working on one 21:15:31 <vishy> I'm also improving a couple of things to make it easier and more robust 21:15:31 <maurosr_> Yes 21:16:36 <markmc> vishy, are we really likely to get all the extension tests done? 21:16:53 <vishy> markmc: doubtful 21:17:02 <vishy> since a number of them have no xml support 21:17:42 <vishy> but I would like to get as many done as possible 21:17:52 <vishy> especially the user facing ones 21:18:13 <dprince> vishy: is this a higher priority than finding/fixing other bugs though? 21:18:21 * markmc was about to say 21:18:30 <markmc> is this distracting us from regressions 21:18:34 <vishy> dprince: I'm not really sure about that 21:18:35 * dprince is focussed on extending SmokeStack to find things at this point. 21:18:38 <markmc> stuff like cinder and quantum integration 21:19:09 <vishy> I think it is fine if most of core is focused on other things 21:19:25 <vishy> I've been hoping that people who complain so vocally about xml would help 21:19:36 <vishy> but only dansmith and his team have stepped up 21:19:38 <markmc> vishy, well, that's certainly reasonable 21:19:46 <dansmith> vishy: we're still trying to wedge some tempest stuff in and fix a couple of bugs found in the process, but we're planning to take a look (mauro being the first to free up) 21:20:05 <vishy> dansmith: ok we will just have to get as much done as we can :) 21:20:10 <vishy> next topic 21:20:17 <dansmith> vishy: we were kindly asked to keep the dep queue down a bit, so there's at least one thing we haven't submitted to gerrit for tempest because it depends on us fixing a nova bug first 21:20:19 <vishy> #topic Bug Triage 21:20:33 <markmc> vishy, you skipped one :) 21:20:45 <markmc> but bug triage first is fine by me too :) 21:20:54 <markmc> we're down to 40 from 100 last week 21:20:57 <vishy> markmc: oh sorry didn't refresh 21:21:12 * vishy didn't do my 20 requested triages from last week 21:21:18 * vishy will do them today 21:21:18 <markmc> any help with triaging would be much appreciated 21:21:20 * dprince got about 15 21:21:25 <markmc> from more than just vishy :) 21:21:27 <markmc> dprince, awesome 21:21:36 <jk0> I can help with that as well 21:21:45 <markmc> I actually came across more valid/interesting bugs than I expected 21:21:46 * russellb did a few ... will keep trying to do more 21:21:52 <markmc> coolness 21:21:59 <markmc> so, it's definitely not wasted effort 21:22:12 <markmc> don't forget to target against folsom-rc1 if you think we should fix before release 21:22:22 <markmc> we can always untarget again later 21:22:56 <dprince> Hey. So I assigned a few powervm tickets to rc1. They look pretty low hanging fruit I think. Mostly just bit-rot I think. 21:23:21 <dansmith> dprince: yep 21:23:21 <vishy> there is a hyperv issue I was hoping to give to the hyperv team 21:23:33 <vishy> came in from the update_available_resource code 21:23:42 <dansmith> yeah, we had one of those too 21:23:42 <vishy> the hyperv methods were not changed 21:23:53 <dprince> Just looked. Tiago seems to have grabbed them. 21:24:29 <vishy> ok moving on 21:24:44 <vishy> #topic Removing 1.x RPC APIs 21:24:57 <vishy> I totally buy the logic for just versioning up to 2.0 21:25:05 <russellb> same, +1. 21:25:26 <markmc> cool 21:25:27 <dprince> So when would we need to start versioning for 2.0 then? 21:25:33 <markmc> we probably should have done it earlier 21:25:40 * markmc doesn't like that it's so close to release 21:25:55 <markmc> but ... russellb and I only realized lately we should go ahead and do it 21:26:04 <markmc> dprince, how do you mean? 21:26:06 * dprince is behind in this conversation. 21:26:19 <dprince> markmc: looking at your merge props now... 21:26:28 <markmc> dprince, start with https://review.openstack.org/#/c/12156/ 21:26:34 <markmc> dprince, rationale in the commit message 21:26:52 <markmc> wow, that's not right 21:26:54 * timello aka Tiago Mello :) 21:26:54 <markmc> one sec 21:27:11 <dprince> markmc: that is a glance review sir? 21:27:17 <markmc> dprince, https://review.openstack.org/#/c/12056/2 21:27:33 <dprince> markmc: thanks! 21:28:09 <markmc> basically, schema changes break the ability for older controllers to work with new compute nodes all the time 21:28:23 <markmc> the versioning helps folks deploying trunka 21:28:30 <markmc> and gives good error messages etc. 21:28:40 <markmc> but there's no point in retaining compat over a long period 21:28:44 <dprince> got it. 21:28:45 <markmc> until we have no-db-compute 21:29:13 <dprince> Although, I'm certainly going to forget this at some point. At which point I'll just bug Russell 21:29:16 <russellb> so until then, we can do a series of changes, backwards compat along the way, then one big removal when the series is done 21:29:28 <russellb> like was done in the last couple months for compute and schedulre 21:29:34 <russellb> and then markmc cleaned it up now :) 21:29:46 <vishy> so what if we have a bug fix that needs a change after we switch to 2.0? 21:29:58 <russellb> 2.1, 2.2, etc 21:30:04 <markmc> right 21:30:12 <russellb> backwards compat usually isn't that hard 21:30:15 <markmc> there's no harm in having a little bit of backwards compat stuff 21:30:20 <markmc> but it was getting out of hand 21:30:21 <russellb> unless you totally rework how something is done (like live migration) 21:30:40 <markmc> or the request_spec['instance_uuids'] stuff 21:31:28 <vishy> seems like we should be on 2.0 at folsom release 21:31:34 <russellb> so sounds like nobody disagrees with letting this go in 21:31:37 <vishy> but I will assume we won't need to make any changes :) 21:31:39 <markmc> cool 21:31:42 <russellb> vishy: but it won't hurt if it's 2.3 or whatever 21:31:51 <markmc> well, folks just need to do reviews then :) 21:31:56 <markmc> some of it got fairly gnarly 21:32:09 <vishy> does it hurt people like hp who are going to do live upgrades? 21:32:21 <vishy> * attempt to do a live upgrade from essex to folsom 21:32:29 <markmc> nope 21:32:34 <russellb> no, they were screwed anyway 21:32:35 <markmc> schema changes screw them anyway 21:32:41 <russellb> markmc: :) 21:32:49 <markmc> heh 21:32:52 <vishy> ok 21:32:54 <vishy> cool 21:33:17 <vishy> #action merge the 1.x -> 2.0 changes 21:33:24 <vishy> #topic Critical Bugs 21:33:32 <vishy> any new ones that don't have someone working on them? 21:34:05 <dprince> doesn't look like it. 21:34:09 <markmc> there are basically two sets of critical bugs 21:34:20 <markmc> the quantum integration ones, and there are a few of those 21:34:39 <markmc> and cinder/nova-volumes regressions related to the persistent tgtadm/iscsi stuff 21:34:49 * markmc isn't following either too closely yet 21:34:59 <jgriffith> markmc: https://review.openstack.org/#/c/12072/ 21:35:20 <markmc> jgriffith, yep, cool 21:35:36 <markmc> right, they all seem to be being worked by cinder and quantum folks 21:35:51 <vishy> good, i think we are ok there then 21:36:06 <vishy> #topic XML Support in Nova 21:36:16 <vishy> dansmith: anything more to add? 21:36:33 <dansmith> vishy: we've made more progress, but still not there on reviews and merges 21:36:36 <dansmith> vishy: close though 21:36:50 <dansmith> vishy: mtreinish had actually already posted that nova bug fix: 21:36:56 <dansmith> https://review.openstack.org/#/c/12198/ 21:37:18 <markmc> dansmith, on that one ... 21:37:28 <markmc> dansmith, there's actually similar code in the volumes API and cinder 21:38:00 <markmc> dansmith, are you just considering the compute api for now? 21:38:23 <dansmith> mtreinish: you're working on the actual volumes client too, right? 21:38:34 <vishy> that should be fixed in cinder for sure 21:38:55 <dansmith> markmc: you're just saying he needs to submit a similar fix to cinder, right? 21:39:16 <mtreinish> dansmith: I was working on the volumes client in tempest which is agains the volumes extension I think 21:39:24 <markmc> dansmith, well, not really - the fix is for the volumes extension in the compute API 21:39:39 <markmc> dansmith, could be a valid approach to ignore the volumes API itself and cinder for now 21:39:45 <markmc> dansmith, that's why I asked :) 21:40:18 <dansmith> markmc: yeah, I dunno, I guess I'll have to defer to mtreinish 21:40:44 <dansmith> I've personally been working on compute testing, so I haven't had to try to run tempest against cinder instead of nova-volume 21:41:48 <dansmith> I think mtreinish targeted the bug against both nova and cinder though, IIRC 21:42:13 <markmc> ok, cool 21:42:17 <markmc> carry on, sorry :) 21:42:27 <dansmith> https://bugs.launchpad.net/nova/+bug/1040891 21:42:28 <uvirtbot> Launchpad bug 1040891 in nova "XML formatting for volume metadata incorrect" [High,In progress] 21:42:28 <dansmith> yep ^ 21:42:31 <dansmith> np 21:43:11 <vishy> great 21:43:17 <vishy> #topic Open Discussion 21:43:40 * jgriffith could use help with cinder reviews from folks that have bandwidth 21:44:26 <markmc> #help cinder reviews need love too! 21:44:32 <markmc> also 21:44:53 <markmc> we're supposed to at least be considering doing an RC1 this day next week 21:45:15 <markmc> I guess we should at least aim to have a better idea of what the real release blockers are 21:45:20 <jog0> nova os-simple-tenant-usage bug: https://bugs.launchpad.net/bugs/1043999 21:45:22 <uvirtbot> Launchpad bug 1043999 in nova "nova usage-list returns wrong usage" [Medium,Confirmed] 21:45:24 <markmc> so that we can hope for an RC1 the week after 21:45:52 <vishy> markmc: sounds good 21:46:01 <markmc> jog0, targeted 21:46:19 <jog0> markmc: thanks 21:46:23 <markmc> jog0, like everything else, though, it may be dropped if no-one volunteers and we figure out it's not a real release blocker 21:46:31 * markmc throws some disclaimers about 21:47:24 <markmc> maybe that should be the plan ... 21:47:33 <jog0> makes sense, but its been unusable since Essex. 21:47:52 <markmc> this day next week, only true release blockers or bugs with folks actively working on patches 21:48:00 <markmc> should be left on targeted 21:48:01 <russellb> but nobody complained until 3 hours ago :) 21:48:33 <markmc> right, sounds like a good candidate to drop from the blocker list next week if no-one is fixing :) 21:48:42 <russellb> yeah, though it's probably not that hard to fix 21:48:47 <russellb> jog0: were you going to work on it? 21:49:24 <jog0> russellb: not yet, but it looks like its related to the start and end dates 21:49:40 <jog0> horizon uses the extension correctly but the CLI doesn't 21:50:01 <russellb> jog0: k, just assign it to yourself if you work on it, i may look at it and don't want to duplicate effort 21:50:26 <markmc> russellb, jog0, so it sounds like a novaclient issue? 21:50:29 <jog0> russellb: will do. I haven't started working on it yet though 21:50:33 <russellb> k 21:50:37 <dprince> markmc: I'd like to get this in for zmq: https://review.openstack.org/#/c/12223/ 21:50:49 <dprince> markmc: Eric seems to buy it. 21:50:51 <russellb> markmc: haven't gone that deep. but maybe. 21:51:14 <markmc> dprince, ah, thanks 21:51:19 <jog0> markmc: it may be related to both novaclient and nova. Nova shouldn't return bad information if the params are slightly off though 21:52:18 <markmc> jog0, would be good to include --debug output in the bug 21:52:27 <markmc> anyway, we digress 21:52:58 <russellb> open discussion == digression time 21:53:28 <russellb> anything else? 21:53:47 <vishy> ok we're done 21:53:50 <vishy> thanks everyone 21:53:55 <markmc> cool, thanks 21:54:01 <vishy> #endmeeting nova