21:02:14 <russellb> #startmeeting nova
21:02:15 <openstack> Meeting started Thu Dec 13 21:02:14 2012 UTC.  The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:18 <openstack> The meeting name has been set to 'nova'
21:02:25 <russellb> who's here
21:02:28 <dansmith> yo
21:02:31 <ndipanov> hola
21:02:34 * maurosr o/
21:02:46 <devananda> o/
21:02:52 <vishy> hi
21:03:01 <sdague> here, though debuging the flakey, so distracted
21:03:02 <russellb> yay, people!
21:03:02 <markmc> yo
21:03:16 <russellb> #link http://wiki.openstack.org/Meetings/Nova
21:03:32 <russellb> #chair vishy
21:03:33 <openstack> Current chairs: russellb vishy
21:03:43 <russellb> vishy: want to drive?
21:05:12 <russellb> well, feel free to at any point if you'd like
21:05:17 <russellb> #topic bugs
21:05:25 <russellb> figured we'd start with bugs since it's technically a bug squash day
21:05:35 <russellb> mikal put up these stats: http://www.stillhq.com/openstack/triage/nova-20121213.txt
21:05:48 <russellb> markmc says they're bias toward showing how awesome mikal is
21:05:51 <russellb> :)
21:06:06 <russellb> so, who has done some bug squashing today?
21:06:15 <dansmith> o/
21:06:21 <russellb> I wish I could say I've done more ... hoping to put some hours into it post meeting ...
21:06:48 <russellb> also relevant: http://wiki.openstack.org/bugstats/
21:07:02 <markmc> small bit of bug triage, fixed a single bug :(
21:07:18 <markmc> on the bug triage thing, mikal has gone through a heap of bugs
21:07:26 <russellb> yeah looks like it
21:07:30 <markmc> but it seems to be New -> Triaged with no comment
21:07:30 <russellb> any revelations from triaging today?
21:07:40 <markmc> I always try and leave a comment
21:07:47 <russellb> mikal: ^
21:07:48 <markmc> about why I think it's a valid bug or whatever
21:07:55 <markmc> yeah, he's not here
21:07:58 <russellb> yeah that makes sense
21:08:31 <russellb> any specific bugs you came across worth drawing attention to?
21:08:41 <russellb> other than "wow, there are still a lot of bugs in there, we should fix some"
21:08:59 <markmc> not me, I mostly was asking for more info
21:09:01 <mikal> Hmmm, I am sort of there
21:09:04 <mikal> Here even
21:09:13 <mikal> I didn't realize we expected a comment during triage
21:09:14 <markmc> sorry mikal
21:09:22 <markmc> well, we've never discussed it I guess
21:09:28 <mikal> I've mostly be going "sure looks like a thing to me, and determining severity"
21:09:41 <mikal> I haven't been reading the code to find the exact source of said bug though
21:09:42 <comstud> oops, i'm here. (thought other chan was -meeting:)
21:09:47 <mikal> I think that would take too long for triage
21:09:53 <mikal> And is somethign I'd expect the person fixing the bug to do
21:09:57 <mikal> But perhaps I'm wrong?
21:10:12 <maurosr> yeah I was about to ask that
21:10:20 <maurosr> I'm trying to get more involved in these things, so bug triage process: is just about to confirm the existence of the bug? should I be converned with an idea to fix it too
21:10:25 <comstud> russellb: i'm squashing bugs in my new cells code.  does that count?
21:10:28 <maurosr> *concerned
21:10:37 <russellb> comstud: sure
21:10:45 <mikal> If you've read the code enough to find the source of the bug, I suspect you should just fix it
21:10:48 <markmc> mikal, most important thing probably is to make sure the person fixing the bug has enough info
21:10:54 <russellb> comstud: actually i should say no, not until you get it merged :-p
21:10:54 <mikal> Why drop all that state on the floor and make the next person start from scratch?
21:11:04 <markmc> mikal, because while the bug is fresh is the best opportunity to go back and ask for more info
21:11:05 <comstud> russellb: dang
21:11:32 <mikal> markmc: that's a fair point
21:11:34 <markmc> mikal, so, I try and make sure there's enough info to reproduce or debug or get a rough idea of what the bug is
21:11:44 <markmc> mikal, and then dump everything I figured out in a comment and move on
21:11:48 <markmc> mikal, it can be time consuming, agreed
21:12:22 <russellb> sort of related ... for anyone new to doing openstack bug triage, check out: http://wiki.openstack.org/BugTriage
21:12:33 <maurosr> thanks
21:12:35 <mikal> markmc: sure, I can do more of that
21:12:46 <markmc> cool, was just curious what folks thought
21:12:47 <mikal> I didn't realize we wanted to go that far with triage, but that's fine
21:13:53 <russellb> done with bugs?  i don't have any more to talk about there ... *slaps own wrist for not triaging enough*
21:14:22 * dansmith retracts wrists
21:14:29 <russellb> heh
21:14:32 <russellb> #topic blueprints
21:14:40 <russellb> let's hit status on various projects, based on who's around ...
21:14:44 <russellb> cells!  https://blueprints.launchpad.net/nova/+spec/nova-compute-cells
21:14:48 <comstud> woo!
21:14:51 <russellb> comstud: eta on updates?
21:15:00 <comstud> i feel like i've basically rewritten it at this point
21:15:01 <comstud> lol
21:15:07 <russellb> lol
21:15:08 <comstud> although not quite
21:15:15 <comstud> anyway, i feel this is looking much better
21:15:26 <comstud> I'm working on fixing tests
21:15:34 <comstud> i may push up a review w/o working tests in a bit
21:15:40 <comstud> so i can start getting some feedback
21:15:40 <hemna> hey guys, I have a question about my blueprint for Fibre channel support in Nova
21:15:52 <russellb> hemna: k, it's in the queue :)
21:15:58 <hemna> ok cool.
21:16:11 <russellb> comstud: sure, as long as you're fairly confident test fixes won't drastically change the implementation
21:16:29 <comstud> nod
21:16:42 <comstud> we'll see where i get in the next couple hrs
21:16:46 <comstud> i gotta grab lunch yet
21:16:47 <russellb> or if it's just another day or something, could just wait
21:16:48 <russellb> k
21:16:51 <russellb> yes food is good
21:17:13 <russellb> cool, well sounds like still making good progress
21:17:24 <comstud> it's going.. it sat for a bit from being sick
21:17:30 <comstud> (still sick, really, but much better)
21:17:34 <russellb> keep eyes on grizzly-2 :)
21:17:37 <comstud> yep
21:17:39 <russellb> cool, glad you're better this week
21:17:46 <russellb> anything else?
21:17:46 <comstud> eyes on the prize
21:17:50 <russellb> yup yup
21:17:51 <comstud> nope
21:17:55 <russellb> k
21:18:01 <russellb> hemna: alright, you're up, link to the blueprint?
21:18:07 <hemna> https://blueprints.launchpad.net/nova/+spec/libvirt-fibre-channel
21:18:25 <hemna> so most of the content of the bp is in the cinder project
21:18:37 <hemna> but we have to make changes in libvirt to support fibre channel
21:18:53 <hemna> So we created a BP for nova, but linked the contents to the BP in cinder
21:18:54 <hemna> hope that is ok
21:19:07 <russellb> the libvirt driver you  mean, right?
21:19:09 <vishy> its fine
21:19:09 <russellb> not libvirt itself
21:19:12 <hemna> affirmative
21:19:26 <russellb> cool, seems reasonable, have an ETA on the implementation?
21:19:27 <hemna> we have a working proof of concept already
21:19:54 <dansmith> in gerrit?
21:19:55 <hemna> we gave a demo of it and a code review today to jgriffith
21:20:05 <hemna> we can't submit the code to gerrit just yet
21:20:09 <alexpilotti> hemna: do you already have changes for the nova APIs?
21:20:15 <hemna> as we are waiting for HP legal to ok it all
21:20:25 <hemna> no API changes needed
21:20:33 <alexpilotti> hemna: I'm interested as we plan to support FC in Hyper-V pretty soon and it'd be great to have a common plan
21:20:34 <hemna> the changes are pretty small actually
21:20:41 <russellb> so perhaps we should wait on approving it for grizzly until you have approval to release code ...
21:20:58 <hemna> the legal process is in the last stages
21:21:01 <dansmith> and given the drop approach, maybe until we see it a little too
21:21:01 <hemna> it could be a week or 2
21:21:09 <hemna> our plan was to get it in G3
21:21:34 <russellb> vishy: want to just approve it and set to g3?
21:21:45 <russellb> vishy: i guess it can be pulled out later if it gets blocked
21:21:48 <hemna> the cinder BP was approved already fwiw
21:22:33 <russellb> ok, any other questions/issues with it for now?
21:22:44 <hemna> we wouldn't be opposed to giving someone from the nova team a demo
21:22:44 <russellb> or just wanted to make sure it was filed appropriately?
21:22:53 <hemna> just as long as it's 1 or 2 folks at most
21:23:04 <vishy> done
21:23:09 <russellb> vishy: great thanks
21:23:13 <hemna> just wanted to raise awareness and see if we can get the BP approved
21:23:24 <hemna> great thanks
21:23:52 <russellb> cool, alright, anyone else want to discuss blueprint status?
21:24:00 <russellb> dansmith: guess we could do a no-db-compute update
21:24:07 <ndipanov> russellb, can I pitch my bp while I'm here
21:24:15 <vishy> i haven't had any chance to work on the improve-block-device-handling
21:24:16 <dansmith> russellb: sure
21:24:25 <kmartin> alexpilotti: I work with hemna, and we have a weekly meeting with a number of companies(IBM, Brocade, EMC, etc...) to have a common solution., send me PM with your email and we can added you to the meeting if your interested
21:24:25 <vishy> although I was wondering if maybe ndipanov wanted to take it
21:24:42 <ndipanov> vishy, that sounds like it has smth to do with my stuff
21:24:45 <devananda> russellb: I would like to talk about baremetal at some point (whether that's under the heading of bp or not doesn't matter)
21:24:46 <alexpilotti> kmartin: tx
21:24:54 <russellb> devananda: ok cool, in the queue
21:25:19 <ndipanov> vishy, what's the bp link?
21:25:26 <russellb> ndipanov: want to talk about what you're doing? and then we can look at improve-block-device-handling too
21:25:34 <ndipanov> russellb, sure
21:25:36 <russellb> https://blueprints.launchpad.net/nova/+spec/improve-block-device-handling
21:25:45 <vishy> ndipanov: https://blueprints.launchpad.net/nova/+spec/improve-block-device-handling
21:25:49 <vishy> durn it
21:25:55 <ndipanov> vishy thanks
21:25:59 <russellb> https://blueprints.launchpad.net/nova/+spec/improve-boot-from-volume
21:26:05 <russellb> looks like we haven't approved that one yet
21:26:27 <russellb> ndipanov: what's the status?
21:26:54 <ndipanov> russellb, I am waiting for cinder guys to accept an API change
21:27:02 <ndipanov> it's an extension
21:27:28 <ndipanov> I've pinged jgriffith about it today so it seems to be in the works
21:28:01 <russellb> cool
21:28:02 <ndipanov> after that, I'm planning to follow up with a change in how nova handles metadata for volumes
21:28:22 <ndipanov> and the block device thing is actually something I will have to look into at one point
21:28:30 <ndipanov> also might be relevant:
21:28:34 <vishy> just approved the bp
21:28:41 <vishy> set it for g-3 since there a bunch of steps
21:29:17 * ndipanov looking for a bug
21:29:41 <ndipanov> https://bugs.launchpad.net/nova/+bug/1075971
21:29:43 <uvirtbot> Launchpad bug 1075971 in nova "Attach volume with libvirt disregards target device but still reserves it" [Undecided,New]
21:30:43 <ndipanov> so russellb that's what;s coming from me in the next week or so
21:30:48 <russellb> ndipanov: great
21:30:58 <russellb> ndipanov: want to assign yourself improve-block-device-handling for now as well?
21:31:06 <russellb> tentatively at least :)
21:31:24 <russellb> if you might end up working on parts of it anyway
21:31:51 <ndipanov> yeah - I'll have to brush on it
21:31:57 <ndipanov> tentatively - yes! :)
21:32:17 <russellb> ok, assigned
21:32:21 <ndipanov> and if I get snowed in, I'll scream for help :)
21:32:27 <russellb> excellent
21:32:38 <russellb> either if it doesn't end up  overlapping with your work, or you don't have the time, etc
21:32:49 <russellb> scream then too ... anyway, i'm not worried :)
21:32:55 <ndipanov> makes sense sice I would have to figure out bits of it
21:32:57 <russellb> ok, next blueprint ... baremetal!
21:33:05 <russellb> devananda: annnnnnd go
21:33:18 <devananda> #link https://blueprints.launchpad.net/nova/+spec/general-bare-metal-provisioning-framework
21:33:33 <devananda> so there's been a lot of good feedback on the main reviews recently
21:33:48 <devananda> i'm really hoping that they can get approved soon
21:34:24 <devananda> a few major (valid) concerns were raised with both of the new binaries
21:34:52 <devananda> i created a new BP to explain our intent to rewrite one of those, hopefully enough to allow nova-baremetal-deploy-helper to land so we can use it while we rewrite it
21:35:30 <russellb> slippery slope there :)
21:35:46 <russellb> what's the major concern that has to be deferred?
21:35:57 <devananda> indeed. and if that's not acceptable, we can live with keeping some things out of trunk
21:36:06 <devananda> #link https://blueprints.launchpad.net/nova/+spec/improve-baremetal-pxe-deploy
21:36:10 <devananda> it's explained there :)
21:36:58 <devananda> if the main patches (11354, 11088) can land, the others are either very small, or less important
21:37:03 <russellb> ah, the desired approach there is quite fundamentally different
21:37:24 <devananda> yes. we definitely won't have the desired approach for scalable deployments by grizzly...
21:37:39 <russellb> ok, i just want to be careful on mass disruption to the user base
21:37:59 <russellb> could document it as experimental in grizzly if it comes to it and likely subject to major changes
21:38:11 <russellb> just need to set proper expectations
21:38:20 <lifeless> +1
21:38:30 <devananda> sure. and to reiterate, that experimental bit refers only to the deploy process, not the rest of the driver :)
21:38:38 <russellb> cool
21:38:51 <russellb> so, who's reviewing the major patches?
21:38:53 <russellb> (from nova-core)
21:38:58 <russellb> well, and not nova-core
21:39:18 <dansmith> I had been in the past, and need to get back to it
21:39:24 <dansmith> I think sdague had some comments recently
21:39:42 <russellb> ok great, just would like to see major patches have at least 1 nova-core "sponsor" that's looking after it, and helping to keep it moving
21:39:55 <devananda> we've had various people come in at different times to give input, but i dont think anyone has consistenty stuck around :(
21:39:58 <sdague> I was going through baremetal, I'll take another whack at it tomorrow
21:40:04 <devananda> sdague: thanks much
21:40:08 <russellb> great, thanks a lot guys
21:40:22 <russellb> anything else on baremetal this week?
21:40:45 <devananda> just chugging along, getting closer to running CI but not quite there yet
21:40:57 <devananda> that's all
21:41:19 <russellb> cool thanks!
21:41:27 <russellb> so, how about the get-password blueprint
21:41:30 <russellb> vishy: ^
21:41:40 <russellb> alexpilotti requested this as a topic last week, and we punted to this week
21:41:43 <vishy> that is going well
21:41:48 <vishy> ah ok
21:41:53 <alexpilotti> russellb: tx
21:42:33 <alexpilotti> vishy: I saw that your patch is close to approval and as I said I plan to to support it in the Windows cloud-init
21:43:09 <alexpilotti> vishy: I laso think that it's an almost mandatory way to go for some driver's, e.g. baremetal
21:43:22 <russellb> https://review.openstack.org/#/c/17274
21:43:30 <alexpilotti> vishy: while on Hyper-V, KVM and probably other hypervisors we have more options
21:43:32 <russellb> https://blueprints.launchpad.net/nova/+spec/get-password
21:43:54 <alexpilotti> there are quite a lot of reasons why guest access to the metadata APIs is problematic
21:44:30 <alexpilotti> at least on Hyper-V we could exploit the KVP exchange to pass small data from the guest to the host
21:44:53 <russellb> alexpilotti: so are you pretty much just in strong agreement with the feature?  :)
21:45:42 <alexpilotti> I could implement it as an Hyper-V only feature, but I think that it could be applied to KVM and more
21:46:08 <alexpilotti> I'd like to know your opinion about this
21:46:16 <alexpilotti> before going to do a bp
21:46:32 <vishy> "exploit the kvp exchange"
21:46:53 <vishy> ?
21:47:04 <vishy> i don't know what you mean by this
21:47:23 <alexpilotti> vishy: sure
21:47:40 <alexpilotti> there's a feature in Hyper-V called KVP Exchange, I'm looking for a link to sone doc
21:47:52 <lifeless> alexpilotti: the metadata APIs exist solely for guest access. Whats problematic about it ?
21:48:19 <alexpilotti> it's a simple communication channel  where a dictionary can be shared between host and guest
21:48:47 <alexpilotti> lifeless: not for updates
21:49:16 <alexpilotti> beside that, we are preferriing teh ConfigDrive
21:49:31 <alexpilotti> which enables us to ditch the metadata API altogether
21:49:59 <lifeless> alexpilotti: thats interesting. For baremetal we want to depend exclusively on the metadata API
21:50:03 <lifeless> :)
21:50:06 <alexpilotti> having to support metadata API for password update brings the issue back
21:50:31 <alexpilotti> lifeless: that's why at the beginning I said that for baremetal there's almost no other option ;-)
21:50:43 <alexpilotti> but for the rest, there's hope :-D
21:50:57 <alexpilotti> KVM has VMChannel
21:51:06 <russellb> ok, so is it ok to move to the next topic?  otherwise, let's punt this to the mailing list if it needs more discussion
21:51:09 <alexpilotti> Hyper-V has the KVP exchange
21:51:16 <lifeless> alexpilotti: ok. Well, I guess from my perspsective if we having the metadata service reliably, we should fix whatever issues there are in it, rather than saying that baremetal will be second class.
21:51:18 <russellb> 9 minutes left
21:51:22 <lifeless> -> list IMO.
21:51:32 <vishy> yes list
21:51:38 <alexpilotti> vishy: ok
21:51:39 <russellb> great thanks guys
21:51:46 <russellb> dansmith: no-db-compute, go!
21:51:56 <vishy> host-guest communication channel discussion ftw :)
21:52:07 <dansmith> so,
21:52:15 <dansmith> with these patches approved:
21:52:20 <dansmith> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/no-db-compute-manager,n,z
21:52:30 <dansmith> we'll have all of virtapi's database stuff directed at conductor
21:52:46 <dansmith> which leaves just whatever remains in compute/manager.py for finishing no-db-compute-manager,
21:52:51 <dansmith> which is pretty good progress, IMHO
21:53:03 <russellb> cool, and our goal with that milestone is grizzly-2
21:53:13 <russellb> (all of compute/manager.py not hitting the db directly)
21:53:18 <dansmith> I think that there are probably some gotchas that prevent that from being the end of no-db-compute, but I haven't surveyed other stuff yet
21:53:34 <russellb> nice work dansmith, really appreciate all of your help
21:53:51 <dansmith> something that someone asked me the other day, is whether no-db-compute includes nova-network,  and my answer was no
21:53:52 <dansmith> agree?
21:54:08 <russellb> yes, agree
21:54:31 <dansmith> cool, so I expect early in january, I'll have a better idea of what's really remaining before we can close the faucet to nova-compute
21:54:45 <russellb> biggest gotcha remaining is the servicegroup api I believe
21:54:49 <dansmith> okay
21:54:59 <ndipanov> russellb, dansmith I saw a patch a few days ago that attempts to bring back db access - should we ping u guys when we see such stuff
21:55:09 <russellb> yeah, or just -1 it :)
21:55:10 <dansmith> ndipanov: sure, what patch was it?
21:55:16 <ndipanov> one sec
21:55:27 <russellb> but one of us can help guide other ways to do whatever the patch wants to do
21:55:34 <dansmith> sure
21:55:37 <ndipanov> https://review.openstack.org/#/c/17716/
21:55:42 <ndipanov> yeah the patch was ok
21:55:51 <russellb> ndipanov: thanks for looking out
21:56:01 <dansmith> ndipanov: I'll look, thanks
21:56:09 <dansmith> russellb: I wanna make sure we get to maurosr's last item on the list
21:56:19 <dansmith> er, on the agenda I mean
21:56:19 <russellb> k, let's hit it now
21:56:25 <ndipanov> I mentioned it a bit but I am not too deep into no-db-compute so might have been misleading them :)
21:56:29 <alaski> The patch is mine, I'm in progress on removing db access.
21:56:35 <dansmith> alaski: sweet :)
21:56:39 <russellb> alaski: great, thanks!
21:56:48 <russellb> alaski: ping us if you want to discuss it in any detail (outside of meeting)
21:56:51 <russellb> #topic requiring api-samples tests with new extensions
21:56:55 <alaski> russellb: cool, thanks.
21:57:05 <maurosr> ok, it's really a quick and simple question: there are some new extension comming up, should we -1 if the new extension doesn't include api-samples?
21:57:15 <russellb> i think that seems reasonable
21:57:16 * dansmith votes hell yes
21:57:32 <russellb> the api samples tests have come along quite a bit, it has gained "critical mass" i'd say
21:57:38 <maurosr> the alternative is ask the owner to report a bug about it and link with the api-samples bp
21:57:39 <russellb> so seems acceptable to require it from now on IMO
21:57:50 <dansmith> I think it should be required, not optional with a bug
21:58:00 <russellb> +1
21:58:03 <dansmith> should be just part of the onus of adding something
21:58:03 <russellb> any disagreements on that?
21:58:26 <russellb> more agreements are good too :)
21:58:28 * dansmith dubs maurosr the official api_samples policeman
21:58:31 <russellb> for the record!
21:58:36 <russellb> ha, excellent
21:58:46 <alaski> Is there any documentation on how to do that?  I recently went through it and it was not fun to figure out.
21:58:48 <maurosr> hehe..
21:58:48 <dansmith> maurosr: go forth, and -1 :D
21:58:56 <maurosr> alaski: 1 min
21:59:05 <maurosr> https://blueprints.launchpad.net/nova/+spec/nova-api-samples
21:59:16 <maurosr> alaski: ^ it describes the whole process
21:59:21 <dansmith> alaski: it is detailed pretty well at the bottom,
21:59:25 <russellb> #agreed those around all agreed with requiring API samples tests with new extensions
21:59:33 <dansmith> alaski: and we have a lot of folks with battle scars, so feel free to poke us for help
21:59:39 <russellb> #topic open discussion
21:59:44 <russellb> we have a whole 1 minute for open discussion
21:59:47 * clarkb plugs https://review.openstack.org/#/c/18003/ and https://review.openstack.org/#/c/15078/ while nova people are around. 15078 should pass tests once 18003 merges. I will rebase 15078 once 18003 is merged
22:00:00 <markmc> #info just released Nova 2012.2.2! http://wiki.openstack.org/ReleaseNotes/2012.2.2
22:00:09 <russellb> markmc: \o/
22:00:19 <russellb> clarkb: testr stuff?
22:00:23 <markmc> no moar regressions plz
22:00:30 <clarkb> russellb: yes
22:00:46 <clarkb> 15078 adds testr to nvoa and 18003 fixes a test that breaks under testr once in a while
22:00:56 <russellb> clarkb: yay for faster tests :)
22:01:15 <russellb> ok, we're over time ...
22:01:29 <russellb> thanks everyone, feel free to chat in #openstack-nova for any spill over
22:01:32 <russellb> #endmeeting