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