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