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