21:00:41 <vishy> #startmeeting 21:00:42 <openstack> Meeting started Thu Aug 9 21:00:41 2012 UTC. The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:19 <markmc> yo! 21:01:23 <russellb> hi. 21:01:31 <vishy> #link Agenda: http://wiki.openstack.org/Meetings/Nova 21:01:34 <mikal> Oh hai 21:02:00 * markmc clicks 'Subscribe' on that page, keep forgetting about it 21:02:50 <jk0> hi 21:03:09 <vishy> #topic XML Support in Nova 21:03:26 <vishy> so lzyeval was looking into the current support for xml 21:03:34 * vishy digs up the email 21:04:01 <vishy> #link http://etherpad.openstack.org/NovaAPIXMLSupport 21:04:31 <vishy> so a whole bunch of the extensions don't support XML serialization right now 21:04:47 <vishy> * deserialization 21:05:07 <vishy> and because we have no end-to-end xml tests it is likely that the ones that do are broken 21:05:39 <vishy> he also mentioned that some have deserializers but no serializers, so if any post requests take nested data they are likely broken as well 21:05:57 <vishy> so the question is: what do we do about it. 21:06:26 <vishy> option 1) announce in the release notes that xml is not going to be maintained 21:06:50 <vishy> option 2) is file bugs against all the serializers and get those fixed and put together some end-to-end xml testing 21:07:09 <vishy> option 3) ???? 21:07:11 <vishy> any ideas? 21:07:21 <markmc> well, (2) requires a volunteer 21:07:28 <markmc> even to just file the bugs etc. 21:07:47 <vishy> is there another option that I'm not considering? 21:08:00 <russellb> so, put out a call for volunteers to do 2, and in the absence of that getting done, 1? 21:08:05 <vishy> i guess there is a middle ground of checking the most important extensions 21:08:19 <russellb> i guess that's some variation of 2 ... 21:08:27 <markmc> (3) mark it as "experimental" somehow, maybe require a flag to be set for it to be enabled 21:08:36 <vishy> and making sure that basic funcionality works. Saying hey, the cloudpipe controller is json only etc. 21:09:08 <vishy> here is the real question: there are a lot of bugs that can be worked on 21:09:20 <vishy> how do we prioritize xml vs the other set of bugs? 21:09:34 <vishy> and do we lose community support if we say we don't care about xml 21:10:30 <vishy> doesn't sound like we have the answer to that here 21:10:32 <markmc> the main thing is to make the current state clear to everyone 21:10:38 <markmc> you can't force folks to fix it 21:10:49 <markmc> and you're right, it's not like nova-core should drop everything and just fix it 21:10:59 <markmc> and it's not a great option to just remove it either 21:11:04 <vishy> #action vishy to email the list about current state of xml and ask for bug reports and volunteers to fix it. 21:11:05 <eglynn> have many or even any bugs been filed against the current incomplete XML support? 21:11:10 <_0x44> Especially when you consider that the one person who ostensibly cares the most about xml has publicly asked us to kill it. 21:11:24 <vishy> eglynn: the only person i know who filed bugs against it was justinsb 21:11:32 <eglynn> (an indication of whether the community really cares about XML support) 21:11:37 <markmc> _0x44, that's obtuse for any of us who don't know the history 21:11:46 * markmc thinks xml is a nice feature, if it worked 21:12:08 <eglynn> yep agreed, but incomplete/broken is worse in a way ... 21:12:11 <vishy> justinsb was a big java advocate, likes xml, but specifically stated he prefers a working json implementation to a buggy xml implementation 21:12:21 <markmc> heh, ok 21:12:24 <vishy> that is the history :) 21:12:33 <_0x44> markmc: Sorry, justinsb was writing a client for Java and wanted to use the XML apis but couldn't because they're shit. 21:12:47 <markmc> _0x44, cool, thanks 21:12:47 <vishy> ok next topic, we will see if we get any help from the ml. 21:13:04 <vishy> #topic Blueprint / Review Updates 21:13:23 <vishy> mikal: need anything for Config Drive / Metadata? 21:13:28 <vishy> seems to be going well 21:13:33 <mikal> I'm replying to people's reviews now 21:13:42 <markmc> #link https://blueprints.launchpad.net/nova/+spec/general-host-aggregates 21:13:46 <mikal> I think the only hard bit left is nailing down the format for file inject 21:14:01 <mikal> I don't much care what we do 21:14:06 <mikal> I just want the adults to stop fighting 21:14:32 <vishy> mikal: yes any format seems fine 21:14:39 <vishy> mikal: we need a format for network data as well 21:14:47 <mikal> Padraig pointed out a vulnerability in the way its done now 21:14:56 <mikal> So that will need to be tweaked a little at the least 21:15:09 <mikal> At the moment you just get the network data in the format that the inject code gets it 21:15:12 <vishy> mikal: I would say lets just use a simple json/yaml representation 21:15:16 <mikal> (Which I think is what original inject did too) 21:15:36 <russellb> #link https://review.openstack.org/#/c/10934/ 21:15:38 <mikal> Yeah, it would be nice if we could also iterate -- get this code in todayish, and then do another review with tweaks 21:15:40 <vishy> mikal: yeah i suppose that is fine for now, if someone wants to convert it to some standard format for the next version that is fine 21:16:08 <mikal> I'll change to a json flavoured inject this morning, cause it fixes Padraig's concerns too 21:16:19 * vishy put the blueprints out of order on the agenda 21:16:29 <vishy> let me go back to the right order 21:16:32 <vishy> mikal: sounds good 21:16:44 <vishy> back to general host aggregates 21:17:08 <russellb> #link https://review.openstack.org/#/c/10256/ 21:17:08 <vishy> does someone else want to review part 2? 21:17:26 <markmc> #link https://blueprints.launchpad.net/nova/+spec/general-host-aggregates 21:17:55 <russellb> i can review it tomorrow 21:17:59 <vishy> #info we are probably fine pushing this one to grizzly: https://review.openstack.org/#/c/10826/ 21:18:07 <vishy> but we definitely need part 2 in 21:18:16 * comstud is here 21:18:31 <vishy> the above one would be cool, but i won't cry too loudly if it misses 21:18:43 <vishy> still great to review it if someone wants to. Just me so far 21:19:03 <vishy> ok if we get reviews that one is fine 21:19:22 <vishy> #link https://review.openstack.org/#/c/11009/ 21:19:30 <vishy> needs review 21:19:33 <vishy> mtaylor: ^^ 21:19:40 <vishy> status on that fix? 21:20:15 <markmc> #link https://blueprints.launchpad.net/nova/+spec/integrate-python-glanceclient 21:20:49 <vishy> lzyeval: hi 21:20:59 <vishy> lzyeval: we can discuss xml again in a minute 21:21:07 <lzyeval> vishy: sure 21:21:17 <vishy> so reviews on glanceclient are important as well 21:21:56 <vishy> looks like yun mao isn't here 21:22:03 <vishy> i was going to ask if there is more to be done for: 21:22:04 <dprince> vishy: I can look at glanceclient... 21:22:12 <vishy> #link https://blueprints.launchpad.net/nova/+spec/task-management 21:22:16 <vishy> dprince: awesome thanks 21:22:40 <vishy> the server extension blueprint is well underway. The reviews should be easy 21:22:55 <dansmith> vishy: I know of at least one review that seems to be stalled on the state management stuff 21:23:05 <vishy> #link https://review.openstack.org/#/q/topic:bp/disable-server-extensions,n,z 21:23:13 <markmc> dansmith, yeah, this I presume - https://review.openstack.org/#/c/10774/ 21:23:14 <vishy> dansmith: that last delete in any state review? 21:23:21 <dansmith> it's his set-task-state-to-none-after-any-failure one, which is similar to what I almost got done earlier 21:23:30 <markmc> dansmith, haven't gotten around to compare that with your @revert_state patch 21:23:33 <dansmith> markmc: yep 21:23:50 <vishy> yes yun seems to be away for the bast few days 21:23:50 <markmc> dansmith, I was pretty happy with yours fwiw 21:23:53 <dansmith> markmc: well, I asked if I should resurrect mine in the face of Johannes' concerns 21:24:14 <dansmith> markmc: if you think I should just do it, then I will. it's gonna be fairly small now 21:24:24 <vishy> dansmith: might as well reprop it 21:24:29 <markmc> yeah, agree 21:24:29 <dansmith> t'was trying to be polite when I asked, which is so unlike me :) 21:24:40 <dansmith> vishy: a'ight 21:24:49 <vishy> #action dansmith to repropose is revert_state decorator 21:25:11 <vishy> so delete in any state is going well 21:25:15 <vishy> but it will need some approvals 21:25:28 <vishy> there are 4 or 5 more patches to go in but they should all be really simple like the last few 21:25:41 <vishy> sdague: are you still doing the two you have assigned 21:25:48 <vishy> nati_uen_: ditto 21:25:58 <vishy> jk0: are you still planning on helping? 21:26:05 <jk0> yessir 21:26:20 <nati_uen_> vishy: Not started yet. But I'll finish this in this week 21:26:24 <vishy> i did a bunch, so there are only a few left, but helping with reviews would also be awesome 21:26:27 <sdague> vishy: yes, I'll redo the one that I've got already after the rebase confusion tonight, and get to the other one in the morning 21:26:46 <jk0> vishy: had some things come up this week so I wasn't able to help as much as I would have liked 21:27:03 <vishy> jk0: the last few should be pretty easy 21:27:06 <jk0> vishy: but toss reviews my way and I will make time for them 21:27:11 <jk0> ok 21:27:16 <vishy> if you guys don't take them I will probably just bang them out :) 21:27:29 <sdague> it would be nice if https://review.openstack.org/#/c/10816/ landed, because I'd do some refactoring on the tests after that 21:27:30 <vishy> jk0: https://review.openstack.org/#/q/topic:bp/disable-server-extensions,n,z 21:28:07 <sdague> so nova core reviews on that patch by vishy are appreciated 21:28:09 <vishy> sdague: don't know if you saw, but I put three more reviews into the series 21:28:22 <sdague> vishy: I guess I didn't notice that yet, I'll go look 21:28:56 <vishy> still not sure about the plugin framework 21:29:27 <vishy> comstud: can you have someone review this? https://review.openstack.org/#/c/9879/ 21:29:36 <vishy> i think it is good to go, but you guys are the xen users 21:29:45 <_0x44> sdague: I just reviewed it 21:30:01 <vishy> looks like it needs a rebase though 21:30:02 <comstud> sure 21:30:04 <vishy> i will ping renuka 21:30:29 <vishy> but review for content would be good 21:30:38 <vishy> and we can slam it in after rebase 21:30:52 <dansmith> git slam 21:30:53 <dansmith> git: 'slam' is not a git command. See 'git --help'. 21:30:54 <dansmith> hmm 21:31:16 <vishy> hehe 21:31:26 <vishy> so last few 21:31:29 <vishy> bare metal 21:31:44 <vishy> they are splitting it into five patches to make reviewing easier 21:31:51 <vishy> but eyes on those reviews would be awesome 21:31:52 <markmc> oh, awesome 21:32:03 <vishy> they have the first couple up 21:32:07 <vishy> 1 for db 1 for docs 21:32:42 <mikal> The db one is still quite big 21:32:58 <vishy> #action nova-core to help review bare-metal patches 21:33:14 <sdague> vishy: once we get to the end of blueprint round up, I had some questions about additional driver reviews (powervm and storwize) 21:33:15 <vishy> my initial thought is to delay both the ServiceGroup patch and the Cells stuff to post Folsom 21:33:21 <markmc> #link https://blueprints.launchpad.net/nova/+spec/general-bare-metal-provisioning-framework 21:33:21 <vishy> thoughts? 21:33:37 <vishy> #link https://review.openstack.org/10903 21:33:56 <ewindisch> vishy: it might be wishful thinking, but I wanted to use that to supplement the matchmaker. 21:33:59 <markmc> think delaying cells makes sense 21:34:05 <comstud> when is the deadline ? 21:34:06 <ewindisch> (re: ServiceGroup) 21:34:14 <vishy> #link https://review.openstack.org/#/c/10707/ 21:34:15 <markmc> did my best to dig into it, but it's slow going - gnarly (but awesome) stuff 21:34:18 <vishy> Tuesday 21:34:21 <comstud> ya 21:34:50 <markmc> grizzly isn't far away :) 21:35:04 <comstud> i don't have a strong opinion 21:35:12 <markmc> and it's always cool to have some nice big features lined up ready to merge when a new cycle opens 21:35:21 <comstud> i'm not upset if it won't merge for folsom 21:35:22 <vishy> ewindisch: i think the service_group stuff is correct 21:35:34 <vishy> i'm just worried about potentially breaking things 21:35:46 <dansmith> last I checked no-db-compute was still listed for folsom.. assume that should be changed now? 21:35:57 <vishy> it doesn't really give us any value until the other backends are done, so putting it in right now seems a little risky 21:36:07 <vishy> dansmith: i untargetted it for f-3 21:36:09 <russellb> dansmith: correct 21:36:17 <vishy> but grizzly hadn't been created yet so i didn't move it to grizzly 21:36:18 <russellb> ton more work to do, unfortunately 21:36:27 <vishy> #link: https://launchpad.net/nova/+milestone/folsom-3 21:36:31 <vishy> that is the current stuff 21:36:33 <sdague> out of curiosity, when will the grizzly tree open up? 21:36:38 <ewindisch> vishy: The plan is to hopefully move service group into common, by the way. 21:36:40 <dansmith> vishy: ah, okay, I see. still says accepted for folsom, but not targetted.. gotcha 21:37:04 <russellb> dansmith: i think once we cut RCs for folsom ... 21:37:19 <dansmith> russellb: cool 21:37:22 <ewindisch> it might be a good candidate for grizzly -- besides the matchmaker requirements, I think everything else that NEEDS this can/will/should wait for Grizzly. 21:37:49 <vishy> ewindisch: yes that is my thought 21:38:11 <vishy> sdague: I'm not sure last time we opened it after the first rc 21:38:22 <vishy> but it made backporting extremely painful 21:38:30 <vishy> so we might delay it a bit longer 21:38:44 <ewindisch> vishy: by the way, what is the policy on merging from common after Tuesday? 21:38:46 <sdague> ok, no worries. Is there already a grizzly-1 tag in launchpad, so we can target cells and service groups for that? 21:39:07 <russellb> should be no different than any other nova patches ... bug fixes should be fine, features require an exception, right? 21:39:07 <vishy> ewindisch: for bug fixes its fine 21:39:18 <markmc> ewindisch, I'll be locking down common for folsom too 21:39:25 <russellb> markmc: good call 21:39:35 <markmc> russellb, why thank you :) 21:39:41 <sdague> that's actually a very interesting question, should there be an attempt to do a broad common -> nova sync before then. I think a number of things are out of sync atm. 21:39:49 <russellb> i know you just desperately wanted my validation 21:39:52 <markmc> sdague, yep, we should 21:40:02 <markmc> sdague, I'll make sure that happens 21:40:30 <sdague> cool 21:40:33 <markmc> russellb, validate my sad and lonely patch too, then : https://review.openstack.org/#/c/10598/ :) 21:40:50 <russellb> ha, k 21:40:51 <vishy> ok any other reviews that i missed? 21:41:02 <markmc> yes, approx 50 others :) 21:41:07 <markmc> we're up around 60 now 21:41:08 <sdague> heh 21:41:13 <markmc> we had it down to 40 last week 21:41:38 <vishy> :( 21:41:40 <markmc> and we can't even blame it on a slew of no-db-messaging patches 21:41:48 <russellb> :-p 21:41:51 <dprince> lots of +2's so assuming those are looking good it should go down quick. 21:42:04 <dansmith> but we can still blame it on russellb without any justification, right? 21:42:04 <vishy> ok well maybe we need to discuss that in the next topic 21:42:12 <russellb> sure 21:42:14 <comstud> lol 21:42:22 <vishy> #topic Core Work Planning 21:42:36 <vishy> review days have fallen off the map along with soren 21:42:48 <vishy> are they valuable, should we restart them? 21:43:02 <russellb> not IMO ... i think everyone should be trying to do it along the way 21:43:09 <comstud> i usually cannot follow the review days 21:43:15 <mikal> I don't know about others, but having a day assigned to me is awkward because I have to work it around work commitments 21:43:21 <markmc> it used to kick me into action, but I'm trying to keep more regular about it now 21:43:22 <jk0> I'd like to not continue them 21:43:22 <comstud> so I review randomly 21:43:36 <vishy> #link http://173.203.107.207/~soren/stats/nova-30days.json 21:43:44 <vishy> mikal: has been reviewing like a beast 21:43:47 <dprince> review days almost always conflict with schedules... I like the continual model. 21:43:52 <vishy> russellb and markmc as well 21:43:53 <jk0> reason being, I feel like everyone on the core team is responsible enough to do the job w/o being told 21:44:00 <russellb> \o/ 21:44:04 <markmc> smokestack is kicking ass! 21:44:10 <mikal> russellb: hi five! 21:44:14 <vishy> I've never been a fan of review days myself 21:44:15 <comstud> jenkins has been doing its share of reviewing, too 21:44:16 <russellb> i've actually been more slack than usually lately because of no-db-messaging, should be able to pick it back up soon 21:44:18 <comstud> that's good to see 21:44:22 <vishy> but every day is a review day for me 21:44:28 <eglynn> one prob with the review day concept is that the original reviewer may not follow up on revised patch sets that aren't proposed til the next day 21:44:51 <vishy> so we just all have to buckle down and review as much as possible by tuesday 21:45:02 <markmc> eglynn, point 21:45:02 <jk0> yeah, we should just try to get 1 or more done per day minimal, and we'll be in good shape 21:45:03 <vishy> after that it is bugfix reviews which will hopefully be easier 21:45:16 <vishy> so what about bug triaging? 21:45:26 <russellb> markmc: good point or bad point? you just acknowledged that it was a point. 21:45:28 <markmc> one more thing on reviews 21:45:32 <vishy> maybe we just apply the same principle to bugs as soon as f-3 is done? 21:45:37 <markmc> we should try and share tips for keeping on top of reviews 21:45:38 <markmc> e.g. 21:45:56 <markmc> 1) try using 'git review list' rather than the web UI, also 'git review open' and 'git review download' 21:46:16 <markmc> 2) set up a mail filter to put mail notifications for reviews your subscribed to in a special folder, so you follow up 21:46:19 <markmc> etc. 21:46:22 <sdague> markmc: that sounds like it would be an excellent blog post :) 21:46:27 <mikal> I've been using this: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+-reviewer:mikalstill+-owner:mikalstill,n,z 21:46:31 <markmc> sdague, hmm, point 21:47:01 <markmc> mikal, that's a "nova stuff I haven't looked at" query? 21:47:14 <mikal> Yeah, "review targets" is what its called in the bookmark 21:47:25 <mikal> For stuff I've looked at, that's in my personal dashboard already 21:47:42 <dprince> markmc: nice pointers. I still use http://reviewday.ohthree.com/ to try and go after *the important stuff* first. 21:47:56 <markmc> dprince, indeed, reviewday is another one 21:48:12 <mikal> Is there a way to have reviewday show me _only_ nova reviews? 21:48:17 <dprince> sounds like I need to rename now that 'review days' are out of style though :( 21:48:26 * markmc ponders having 'git review list' sort by reviewday score 21:48:31 <markmc> and include test results 21:48:38 <dprince> mikal: I could add tabs for that. 21:48:39 <vishy> mikal: scroll down? 21:48:46 <vishy> mikal: low tech solution :) 21:48:58 <mikal> Yeah, I've been practising my scrolling skills 21:49:08 <markmc> oh, another tip 21:49:17 <markmc> learn gerrit's shortcut keys 21:49:20 <markmc> handy 21:49:38 <markmc> just hit '?' in a review 21:49:39 <jk0> my secret sauce is maintaining inbox 0, so I immediately see and handle new mail 21:50:14 <russellb> i maintain inbox 0 using mail filters. works great. 21:50:21 * jk0 uses no filters 21:50:29 <jk0> just command + a, delete! 21:50:32 <jk0> jk :) 21:50:41 <vishy> do we have a place for handy review tips? 21:50:46 <vishy> in the wiki 21:50:49 <russellb> to the wiki! 21:50:50 * markmc has subscribed to all nova reviews, filters them into a separate folder from "my reviews" 21:51:08 <vishy> #action nova-core to do lots of reviews by Tuesday 21:51:17 <markmc> heh, nice 21:51:24 <sdague> honestly, a blog post on the planet would probably get more attention than the wiki 21:51:46 <vishy> #action nova-core to switch to bug-fixing after F-3 21:51:59 <markmc> vishy, sorry, you moved onto bug triage 21:52:02 <lzyeval> sdague: But everyone should first tip in the wiki 21:52:06 <vishy> sdague: agreed, although I was thinking put stuff in the wiki and email about it 21:52:14 <lzyeval> sdague: and then post it on planet 21:52:17 <vishy> #topic XML redux 21:52:19 <sdague> sure, fair 21:52:26 <vishy> lzyeval: so I shared the etherpad earlier 21:52:31 <vishy> do you have any new information? 21:52:39 <markmc> #action markmc start a ReviewerTips wiki page 21:53:07 <lzyeval> vishy: Well that etherpad is about how many handlers each controllers have xml support 21:53:10 <vishy> we decided to send out an email asking for some help bug reporting and fixing if people care about xml support 21:53:55 <lzyeval> vishy: yeah and so I tried to find a method to do end to end tests 21:54:14 <lzyeval> and it seems only writing unittest would be the answer 21:54:17 <lzyeval> like 21:54:28 <lzyeval> nova/tests/api/openstack/compute/test_images.py 21:54:37 <vishy> lzyeval: my thinking was hack novaclient to do xml in addition to json and run exercises.sh 21:54:42 <vishy> :) 21:55:32 <lzyeval> vishy: then do we write the request format manually? 21:55:50 <lzyeval> vishy: I've seen api.openstack.org for the request and responses for XML 21:56:07 <vishy> well yes we would have to serialize into xml as well as json 21:56:12 <lzyeval> vishy: but suspicious of it being out of date 21:56:24 <vishy> kind of annoying but it would at least give us basic functionality 21:56:43 <lzyeval> vishy: So it would be a form of a smoketest? 21:57:23 <vishy> lzyeval: There are some with xml tests included like: nova/tests/api/openstack/compute/contrib/test_extended_status.py 21:57:48 <vishy> so that helps a bit, but without a little bit of devstack/exercises.sh testing i really have no confidence 21:59:11 <lzyeval> vishy: one last thing is "is it worth the effort"? 21:59:28 <lzyeval> I think we are all thinking of dropping xml 21:59:42 <lzyeval> quantum team also. 22:00:17 <vishy> lzyeval: yes that was the conclusion we came to but I don't think we can just arbitrarily drop it in the current version of the api 22:00:30 <vishy> lzyeval: we just need to give people reasonable expectations about what works 22:01:04 <vishy> i will go to the mailing list with a request for help. If we get none, then we will just have to assume that it doesn't matter and we will tell people not to use it. 22:01:08 <lzyeval> Ok then, but I'll need some help. I'll devise a plan and start post on ML 22:01:20 <lzyeval> vishy: ok 22:01:40 <sdague> vishy: before we wrap up (give time), I'd like to ask about driver reviews. There is a powervm (nova.virt) and storwize (nova.volume) driver out for review, and it would be nice to get some non-ibm eyes on them. 22:02:02 <vishy> sdague: ok 22:02:22 <sdague> the storwize one is in cinder, but it's a cross port to nova-volume in case nova-volume is only deprecated for folsom (not removed) 22:02:36 <vishy> I'm really hoping that we can start keeping those out of tree 22:02:48 <vishy> sdague: if it is in cinder already then we can merge it 22:03:01 <sdague> #link: https://review.openstack.org/#/c/10535/ 22:03:03 <vishy> I'd prefer to keep them aligned as possible before the s3 release 22:03:31 <markmc> another thing worth mentioning is the thread about the default for rpc_backend 22:03:37 <markmc> more nova-core opinions needed 22:03:39 <markmc> #link http://lists.openstack.org/pipermail/openstack-dev/2012-August/000445.html 22:03:40 <sdague> vishy: yes, the storwize team is cross syncing 22:03:54 <vishy> sdague: the powervm one i will try to look at tomorrow 22:04:01 <sdague> vishy: so is the intent to start removing virt drivers entirely? 22:04:18 <sdague> just trying to understand the comment about out of tree 22:04:26 <vishy> separate packages for drivers seems like a really good way to do it 22:04:51 <russellb> though that's certainly not happening for folsom at this point ... 22:05:03 <vishy> sdague: I don't know why nova-core needs to review a bugfix to the storwise driver for example 22:05:04 <sdague> ok, fair, as long as it's consistent. just don't want to make 2 classes of drivers, in and out of tree. 22:05:13 <vishy> russellb: clearly, but we should revisit at the summit 22:05:17 <russellb> fair enough 22:05:19 <sdague> vishy: right, definitely fair 22:05:22 <vishy> for grizzly I'd like to have drivers be packages 22:05:39 <dansmith> packages == separate trees, or ? 22:05:55 <vishy> dansmith: separate trees would probably be easier 22:05:56 <sdague> vishy: that means making a much stronger driver api contract 22:05:56 <markmc> heh, talk about a can of worms for the end of the meeting :) 22:05:58 <dansmith> because they can all be in nova.git and pacakged separately by distros, right? 22:06:07 <markmc> sdague, right 22:06:10 <vishy> dansmith: that might be step one 22:06:42 <vishy> dansmith: if we could get a way to give +2 rights to subtrees that would be amazing 22:06:58 <vishy> so a person could own an approval if it only touched files under a certain tree. 22:06:59 <russellb> so, action: vishy to review new driver for folsom consideration? 22:07:00 <dansmith> I suppose there'd also need to be some CI work done so that all the drivers are checked, even those outside nova.git 22:07:00 <sdague> yeh, ok, so we'll take that one to summit then. I think this gets into the extension points ideas as well 22:07:09 <vishy> russellb: sure 22:07:10 <russellb> before we get too far into the weeds when we're already past the hour :) 22:07:16 <markmc> vishy, yeah, something like that makes good sense 22:07:18 <dansmith> vishy: yeah, that's a good goal, but definitely takes some orchestration to make sure that it doesn't get out of hand 22:07:29 <vishy> #action vishy to review power_vm driver 22:07:32 <russellb> if it's self contained enough, seems like a good candidate for a FFE after the freeze 22:07:44 <sdague> #link: https://review.openstack.org/#/c/9666/ 22:07:45 <russellb> if it doesn't happen in the next few days 22:07:47 <vishy> anything else? 22:08:27 <russellb> you guys all rock. <3 nova. that is all. 22:08:30 <markmc> we appear to have a lot of things going on 22:08:39 <sdague> russellb: +! 22:08:42 <sdague> russellb: +1 22:09:42 <vishy> ok 22:09:48 <vishy> letus continue with reviews then 22:09:54 <vishy> #endmeeting