21:00:09 <mikal> #startmeeting nova
21:00:10 <openstack> Meeting started Thu Feb 12 21:00:09 2015 UTC and is due to finish in 60 minutes.  The chair is mikal. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:13 <openstack> The meeting name has been set to 'nova'
21:00:17 <mikal> Who is here for a nova meeting?
21:00:19 <alaski> o/
21:00:20 <anteaya> o/
21:00:21 <melwitt> o/
21:00:23 <wanyen_> o/
21:00:24 <dansmith> o/
21:00:26 <dims__> o/
21:00:31 <mikal> Yay!
21:00:36 <mikal> #topic Release status
21:00:39 <alevine> o/
21:00:46 <mikal> Ok, so we're in feature freeze for non-priority stuff now
21:00:54 <mikal> We've collected a bunch of FFE requests during this week
21:01:06 <mikal> And the plan is nova-specs-core will meet early next week to discuss them
21:01:14 <mikal> (as announced in John's email last week)
21:01:21 <mikal> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056208.html
21:01:28 <edleafe> o/
21:01:35 <mikal> I don't have much more on that, its just a "please hold"
21:01:47 <mikal> Any other comments or questions on the FFE process?
21:01:59 <wanyen_> I submitted a ffe request for passing capbility to ironic
21:02:06 <mikal> Yep
21:02:20 <mikal> You'll hear back next week once nova-specs-core has had a chance to meet and discuss
21:02:23 <wanyen_> I hope we hope sometime to discuss it today
21:02:38 <alevine> do questions about new features concern the FFE process?
21:02:46 <mikal> One sec
21:03:02 <mikal> wanyen_: sorry, we weren't planning to work through them at this meeting, as half of specs-core is asleep at the moment
21:03:07 <mikal> Hence the meeting next week
21:03:11 <wanyen_> Is/i hope we hope/ I hope we can
21:03:28 <dansmith> mikal: at one point, the discussion sounded like it was to happen in this meeting at this time
21:03:35 <dansmith> so I think probably some people are surprised to not see it happening
21:03:36 <mikal> Huh
21:03:43 <mikal> Ahhh, I see
21:04:13 <mikal> I'm working off John's email, which says a separate meeting (to my reading at least)
21:04:36 <mikal> The deadline for requesting one has also only just closed, so presumably people need time to consider the requests
21:04:48 <mikal> If we need to discuss specifics of some, we can do that in open discussion
21:05:17 <wanyen_> mikal, discuss at open discussion will be fine
21:05:19 <mikal> alevine: now on to you
21:05:35 <mikal> alevine: so yes, the feature freeze blocks all new non-priority features for the rest of kilo
21:05:51 <mikal> alevine: this is intended to free up time and attention to actually finish the priority work for the release
21:06:13 <alevine> sdague suggested to bring up a question of extension needed for this standalone EC2 API project here. It's just about some more properties to show
21:06:30 <mikal> alevine: yep, that's actually in the next meeting topic on the agenda
21:06:33 <mikal> So... please hold!
21:06:40 <alevine> Oh, ok.
21:07:04 <mikal> So, what we said in the announcement email is we'd discuss exceptions next week, and announce results no later than the nova meeting next week
21:07:08 <mikal> But let's move on...
21:07:14 <mikal> #topic Kilo Priorities
21:07:26 <mikal> So, looking at the tracking etherpad
21:07:33 <mikal> #link https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
21:07:45 <mikal> Is there anything that needs to be called out as needing more attention from that list of reviews?
21:08:07 <dansmith> so,
21:08:42 <dansmith> there is a review up that proposes to implement all (I think) of the nova-to-neutron proxy by hackishly redefining the Network object to make calls to neutron instead of nova's DB
21:08:52 <anteaya> #link https://review.openstack.org/#/c/150490/
21:09:11 <dansmith> I'm trying to codify why I hate it, but it's hard to put feelings I have in my stomach into words
21:09:12 <mikal> Yeah, I saw that one during the week but you seemed to be on it
21:09:28 <anteaya> dansmith: what would you like to see as a way forward?
21:09:39 <dansmith> I feel like simple things will work with that, but more complicated cases will require behavioral changes in the API layer
21:09:47 <dansmith> anteaya: what I said in my review: do it at the API layer
21:09:57 <dansmith> and I mean the nova/network api layer
21:10:50 <anteaya> dansmith: is gus' reply incorporated into your solution direction?
21:11:05 <dansmith> anyway, I thought maybe some other people could look at it and see if they think that's a super idea and I'm just crazy
21:11:07 <dansmith> anteaya: yes
21:11:19 <anteaya> great, thanks
21:11:25 <mikal> Reading gus' comment, I think he thinks Dan means the nova-api layer
21:11:32 <anteaya> okay would be great to have other's feedback
21:11:32 <mikal> Not the network-api layer
21:11:36 <mikal> Or am I mis-reading it?
21:11:53 <dansmith> mikal: I think he's maybe confusing several things
21:11:55 <anteaya> if this is the wrong direction, I would like to get folks steered to the mutually agreed upon right direction
21:12:02 <anteaya> if we can agree what that is
21:12:17 <dansmith> mikal: because there are things that nova-api does with network stuff, and things that nova/network/manager does
21:12:42 <anteaya> dansmith: if I can get both you and gus in a venue of some sort, do you think you could clear some things up?
21:12:56 <mikal> So, the specific request here is for other people to take a look at this review and see if they have concerns?
21:13:41 <dansmith> mikal: I think that'd be a good idea, but it's also hard to know whether this is a good step forward without a lot of consideration of the cases we'll cover
21:13:47 <dansmith> mikal: but yes.
21:13:49 * mikal tries to remember how to makea  note in meeting minutes
21:13:59 <anteaya> try # info
21:14:06 <mikal> #info Please review https://review.openstack.org/#/c/150490/
21:14:31 <mikal> Ok, I can also chat to Angus and try to get him some help
21:14:34 <dansmith> doing it at the object layer,
21:14:52 <dansmith> is akin to doing it at the sqlalchemy layer and trying to just make it look like we're storing things the same way, even though we're not
21:15:05 <dansmith> which is, AFAIK, the job of nova/network/neutronv2/api.py
21:15:07 <alaski> I'll have to spend some more time looking, but at first glance I agree with dansmith that this is the wrong api to hide a rpoxy behind
21:15:33 <alaski> it seems like it will end up being limiting at some point
21:15:39 <mikal> Ok, so let's have a look at it in the next day or so and then I can have a chat to Angus about it
21:15:47 <mikal> Given his timezone is very convenient for me
21:16:01 <anteaya> thanks
21:16:02 <mikal> Is there anything else on priority work we need to cover?
21:16:32 <mikal> ...
21:16:36 <mikal> ...
21:16:39 <mikal> I take that as a no
21:16:44 <mikal> So, the other thing is the ec2 work
21:17:01 <mikal> sdague has asked if we should consider adding fixing ec2 to our list of priorities
21:17:08 <mikal> I think this is partially a timing question
21:17:12 <mikal> Its obviously important
21:17:18 <dansmith> here's what I think we should do:
21:17:20 <mikal> Do we think those fixes will be ready for kilo?
21:17:28 <alevine> They are really easy.
21:17:28 <dansmith> I think we should make a special case, and merge the spec for L, since L specs are open
21:17:42 <dansmith> to give them a clear indication that we're ready for them to get going and we bless the direction
21:17:45 <alevine> Actually just expose some info which is already in novaDB in extended attributes for instances.
21:17:59 <sdague> mikal: so actually, it's not fixing ec2 persay, it's one API change on the v2.1 tree
21:18:00 <dansmith> I don't think that adding stuff to our api in K to support this is the best idea
21:18:25 <mikal> So, I'm a bit confused to be honest
21:18:38 <mikal> The big problem we have is borken auth with modern botos
21:18:46 <sdague> mikal: nope, that's fixed
21:18:51 <alevine> mikal: That's fixed
21:18:54 <mikal> Are we going to not try and fix that and instead transition people immediately to stackforge?
21:19:00 <mikal> Oh, huh
21:19:09 <dansmith> we imported the fix from the stackforge project, right?
21:19:11 <mikal> So we're on to the transitioning people part of the plan and I just didn't notice?
21:19:16 <mikal> Nice
21:19:30 <alevine> mikal: pretty much. We actually created a new one and used it for stackforge as well.
21:19:32 <sdague> dansmith: I don't remember the origin
21:19:34 <mikal> So, that reduces the urgency of the API change, yes?
21:19:51 <alevine> dansmith: That was answer to you. Sorry.
21:19:56 <mikal> I think Dan and I are kind of saying the same thing...
21:20:01 <sdague> mikal: the API changes would mean the ec2 api project can make real progress during Kilo
21:20:02 <dansmith> mikal: it means we don't have to worry about a completely non-functional ec2 in kilo
21:20:05 <dims__> dansmith: no it was not ported
21:20:06 <mikal> I'm not sure if we're talking about a priority task for kilo or liberty
21:20:29 <sdague> which means by Vancouver we could maybe have some working replacement code
21:20:46 <mikal> So, I have no problem with a priority task for liberty, so let's just not talk about that bit any more for now
21:20:49 <sdague> if we hold until L opens up, that sticks a couple months delay into the ec2 external effort
21:20:54 <dansmith> sdague: we could do that without merging it into K right?
21:21:01 <alevine> dansmith: The problem is, until nova exposes some of those APIs. Actually a very few ones, the stackforge project either has to go directly to novaDB or have gaps in its functionality
21:21:05 <mikal> Are we really talking about this one API change if we do this in Kilo?
21:21:10 <mikal> Or is there more hidden away as well?
21:21:20 <sdague> as far as I know it's 1 API change
21:21:28 <alevine> mikal: Yes
21:21:29 <sdague> which I think we should do
21:21:30 <dansmith> sdague: 1 change with a bunch of things in it right?
21:21:45 <mikal> Is this change proposed for review already?
21:21:47 <sdague> dansmith: it's ~8 new extended-status attributes
21:21:54 <dansmith> right, okay
21:22:02 <dansmith> my point is,
21:22:10 <alevine> dansmith: High priority are just two - rootDeviceName and deleteOnTermination for volumes. The rest can wait.
21:22:24 <dansmith> if it's just that and it's not complicated, then there's no reason not to just hold off on that because it's not blocking development
21:22:41 <mikal> dansmith: it does delay deployment though right?
21:22:46 <dansmith> but I understand the desire to flip the argument upside down
21:22:48 <dansmith> mikal: yes
21:22:54 <mikal> dansmith: if it means you can't transition until you've deployed liberty
21:22:56 <dansmith> mikal: but that's not what sdague said :)
21:22:59 <sdague> yeh, it seems low risk to me
21:23:14 <dansmith> mikal: it means you can't without the ec2 project reaching in our db
21:23:16 <mikal> So, yeah, I think I want someone to show me the code
21:23:17 <sdague> so I'd rather give the ec2 folks more momentum and do this change
21:23:35 <dansmith> mikal: which it does now
21:23:43 <mikal> Yeah, I hate the db thing
21:23:48 <dansmith> surely
21:23:54 <mikal> So if this change is a couple of lines, I'm inclined to let it in to be hoenst
21:24:02 <mikal> Which is why I'd like to see the proposed patch
21:24:39 <alevine> mikal: Only the spec is ready. There is no code yet, because it was not approved or decided upon. But we can create the patch shortly.
21:25:02 <mikal> alevine: I think that might make this conversation more concrete
21:25:20 <mikal> Especially if the patch is small so the amount of work we're asking you to do is relatively small
21:25:24 <alevine> mikal: Is it ok to create the patch and get back to the subject next week?
21:25:30 <mikal> alevine: yes
21:25:33 <mikal> alevine: I like that plan
21:25:41 <dansmith> let me say one more thing
21:25:43 <alevine> mikal: Great. We'll do that.
21:25:49 <mikal> dansmith: go for it
21:26:24 <dansmith> I don't like that we had a list of priorities, we drew the line about no non-priority stuff at a date, and we're going to take something new which doesn't even have code up and promote it to a priority and merge it after that line on "a whim"
21:26:38 <dansmith> I don't like the precedent it sets and I don't think it's that critical
21:26:39 <mikal> I can see that
21:26:44 <mikal> But that's not what we're doing
21:26:56 <dansmith> but, I want to set the tombstone for ec2 as much as the next guy so whatever
21:27:02 <dansmith> mikal: it totally is
21:27:07 <edleafe> We also didn't make removing ec2 a priority, but are now pushing for it
21:27:10 <dansmith> I mean, aside from the whim part :P
21:27:11 <mikal> I think if we can see the code and assess its impact and importance, then we can talk about it then
21:27:33 <mikal> We haven't said we'll merge it in kilo yet, we're still talking
21:28:13 <sdague> so what are we going to do about the deprecation patch?
21:28:21 <mikal> Yeah, there's that too
21:28:23 <sdague> because that's still vaguely limbo
21:28:28 <mikal> So ttx didn't love it IIRC
21:28:37 <dansmith> I'm +2 on the deprecation patch
21:28:43 <dansmith> ESPECIALLY if we merge this API thing
21:28:44 <mikal> But it seemed mostly about implementation
21:28:51 <mikal> ie. just log instead of marking deprecated
21:29:04 <sdague> dansmith: yeh, so that's part of my reason to want to merge the API change
21:29:09 <dansmith> sdague: I know it is
21:29:16 <sdague> because I think that makes merging the deprecation more reasonable
21:29:25 <mikal> We did something very similar for the zookeeper thing this week with zero debate
21:29:31 <edleafe> sdague: agreed
21:29:35 <sdague> no one uses zookeeper
21:29:46 <dansmith> this is how we do these things, IMHO
21:29:53 <sdague> they actually can't, it's super broken
21:30:50 <sdague> and I'd really like Kilo to have ec2 deprecated, as I think that will help shift effort to the external project
21:30:58 <dansmith> no argument there
21:30:58 <mikal> So my point is what do people think of changing the ec2 deprecation to being like https://review.openstack.org/#/c/152173/3/nova/servicegroup/drivers/zk.py,cm
21:31:01 <mikal> ?
21:31:17 <dansmith> I want the word deprecated
21:31:22 <dansmith> because I'm an ass
21:31:25 <mikal> The objections to the current patch see to me mostly about the specific meaning of that word
21:31:32 <dansmith> and because I think it's the right word
21:31:33 <mikal> sorry, seem to be
21:31:43 <sdague> yeh, so honestly, I also think deprecated is the right word
21:32:01 <sdague> deprecated means "don't use this thing, we're not going to support it in the future"
21:32:07 <dansmith> right
21:32:17 <dansmith> not "it's not tested, but if it works for you, have at it!"
21:32:20 <sdague> which I do think is the state of the world
21:32:27 <mikal> So I am having trouble arguing against you because I agree...
21:32:37 <mikal> The counter argument was "but the replacement isn't ready"
21:32:44 <mikal> And might (theoretically) never be
21:32:51 <dansmith> it doesn't matter
21:33:10 <dansmith> the state of the world is that even if there is no replacement, our ec2 stuff continues to degrade and go unmaintained
21:33:31 * dansmith notes he's being super-negative today
21:33:51 <mikal> So, the review does have five +2s...
21:33:57 <dims__> dansmith: what about the long argument that it's not architecturally correct to have ec2 api proxy to openstack api
21:34:00 <sdague> I also think that's because very few of the core team is knee deep in ec2 any more
21:34:17 <dansmith> dims__: I think that argument is already false
21:34:17 <sdague> which is why past patches weren't getting reviewed
21:34:28 <sdague> reading ec2/cloud.py is interesting
21:34:38 <sdague> almost all the history comes from pre-git days
21:34:38 <dansmith> dims__: the ec2 layer does some really unnatural things to keep working, even though our internal APIs are oriented to be most convenient for our own api layer
21:34:42 <dims__> dansmith: i agree with you, is there consensus?
21:34:47 <sdague> by people that aren't working on openstack anymore
21:34:57 <swamireddy> dansmith: For the reason of unmaintaned - the sub team of EC2 API formed...
21:35:09 <dansmith> swamireddy: it has been formed eight times since I joined the project :)
21:35:21 <dansmith> complete with summit sessions and everything :)
21:35:37 <swamireddy> dansmith:  ok...can we try last chance...as we agreed last meeting...
21:35:43 <mikal> Ok, so
21:35:50 <dansmith> we didn't agree to that :)
21:35:52 <mikal> Let me take this to ttx and ask his advice
21:35:52 <edleafe> sdague: I wrote the first ec2 id to openstack uuid converter. I wanted it to diaff back then
21:36:01 <mikal> Noting that I think we should mark it deprecated as well
21:36:02 <sdague> edleafe: :)
21:36:09 <dansmith> edleafe: nice :)
21:36:22 <sdague> mikal: sure
21:36:23 <mikal> We do need to move on now though
21:36:32 <dansmith> edleafe: that's what I mean about unnatural stuff, by the way, and it's gotten worse I'm sure
21:36:35 <sdague> yep, hopefully we'll have an api patch early next week
21:36:38 <mikal> #action: mikal to talk to ttx about deprecation of nova's internal ec2 implemetnation
21:36:47 <edleafe> dansmith: yep
21:36:48 <sdague> so we can see how risky that would be
21:37:02 <mikal> #topic python-novaclient release
21:37:10 <swamireddy> dansmith: Now, there is good no of people in the team to support ....I see we should try it as last chance and decide @ summit
21:37:22 <mikal> I think the release is unblocked now, yes?
21:37:42 <dansmith> mikal: you're the only one that can do those releases right?
21:37:45 <mikal> jogo has pinned requirements for stable branches, which I think was the only thing blocking this
21:37:55 <dansmith> mikal: I was talking to john and though ti might be good to have at least another tz with those privs
21:37:57 <mikal> dansmith: I think other people can, but traditionally its been a ptl task
21:38:09 <mikal> I'm not sure what privs it needs
21:38:12 <mikal> Certainly LP permissions
21:38:22 <mikal> But I think drivers already have all they need?
21:38:23 <dansmith> mikal: well, might be something to think about
21:38:30 <mikal> I documented the release process on the wiki last time I did it
21:38:32 <dansmith> drivers definitely don't have privs to do that
21:38:36 <dansmith> someone checked
21:38:43 <dansmith> but if that's the intent, that's cool
21:38:47 <mikal> Oh, interesting
21:38:52 <mikal> Yeah, I have no problem with other people doing them
21:38:57 <mikal> Let me do this one because its faster
21:39:02 <mikal> I'll check the docs as I go
21:39:02 <dansmith> sure
21:39:12 <mikal> And then we can open it up to drivers (or some other subset)
21:39:27 <mikal> So, no one sees a reason to not do a release todayish?
21:39:34 <anteaya> the nova-release group can do a client release
21:39:37 <anteaya> #link http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/python-novaclient.config
21:39:45 <anteaya> currently
21:40:07 <mikal> Ahhh, a group on one
21:40:11 <mikal> Thanks for the pointer anteaya
21:40:14 <anteaya> sure
21:40:21 <mikal> #action mikal to do a python-novaclient release
21:40:30 <mikal> #action mikal to make sure release docs are right
21:40:43 <mikal> #action mikal to give a couple more people release perms
21:40:50 <mikal> I think I got all of the plan there
21:40:52 <sdague> so... is the icehouse pin in place ?
21:40:55 <sdague> jogo: ?
21:41:11 <mikal> My reading of the thread was we were good to go
21:41:16 <mikal> But I haven't checked git
21:41:31 <melwitt> sdague: I'm checking
21:41:45 <sdague> yeh, icehouse is pinned
21:41:46 <anteaya> if you want different people to do a novaclient-release then the nova-release change the client acl file to create a new gerrit group
21:41:58 <sdague> python-novaclient>=2.17.0,<2.21
21:42:26 <sdague> so as long as it's 2.21 we're good
21:42:28 <melwitt> pinned on both icehouse and juno. though the pins are slightly different :P juno is <=2.20
21:42:38 <sdague> yeh, juno is autogenerated
21:42:44 <sdague> icehouse is someone doing a thing manually
21:42:52 <melwitt> oh, that explains that
21:42:59 <mikal> So, sounds like we're good to go
21:43:03 <mikal> Let's move on again
21:43:13 <mikal> #topic Gate status
21:43:32 <mikal> mriedem: tell me of your things
21:44:01 <mikal> ...or anyone else
21:44:08 <mikal> Or is it all puppies and kittens this week?
21:44:16 <sdague> the big meltdowns were on requirements issues
21:44:16 <dansmith> I don't think there is anything nova-specific
21:44:32 <mikal> Yeah, I'm not aware of anything, but I like to check anyway
21:44:36 <dansmith> I was really tempted to try to break the new dependency stuff, but I didn't
21:44:36 <mikal> Gonna move on again
21:44:38 <melwitt> there was the wedged stable gate thing I thought
21:44:41 <sdague> I was chasing a unit test race because libvirt driver spawn treads
21:44:51 <dansmith> also threads
21:44:55 <mikal> sdague: yeah, the thread on that one seems mostly to have a plan?
21:44:56 <sdague> also threads
21:45:11 <sdague> mikal: mostly, it pokes up more often than I expected
21:45:38 <dansmith> sdague is applying fire
21:45:44 <mikal> People seem to know what's happening here though
21:45:47 <mikal> So let's move on
21:45:54 <mikal> #topic Bugs
21:46:06 <mikal> I have to say I'm pretty happy with the trivial patch monkey thing
21:46:12 <dansmith> extremely
21:46:12 <mikal> 48 bug fixes merged so far
21:46:20 <dims__> yay!
21:46:28 <mikal> Sure they're all trivial, but its good that we're landing the fixes
21:46:33 <dansmith> I think I feel a trend of the quality slipping a little
21:46:41 <dansmith> which I think is because we're through the super trivial ones
21:46:52 <dansmith> which is mostly good news
21:46:53 <mikal> Oh, interesting
21:47:05 <mikal> As in it might work well for clearing backlogs, but less for ongoing work?
21:47:12 <dims__> i took at stab at cleaning up after our abandon script this morning (bugs were left in "In Ptogress"), about 100 bugs
21:47:13 <sdague> the new trivial ones are definitely not so trivial some times
21:47:20 <dansmith> mikal: we'll see
21:47:29 <dansmith> mikal: we need to stay vigilant on the self-policing of things
21:47:29 <mikal> Let's wait and see how we feel about how the process is working at the summit
21:47:30 <dims__> sdague: y it's getting harder to find easy ones
21:47:45 <mikal> We don't _have_ to always have 20 there
21:47:50 <mikal> If there are sometimes only 5, so be it
21:47:53 <sdague> I think it's a good process though
21:47:54 <dansmith> mikal: tell that to dims__ ! :)
21:48:00 <mikal> Heh
21:48:05 <sdague> because it's also educational about "why this isn't trivial"
21:48:10 <dims__> mikal: it varies between 5-15
21:48:13 <dansmith> sdague: yep
21:48:17 <sdague> which I'm hoping folks are finding useful feedback
21:48:24 <dims__> sdague: yep
21:48:25 <mikal> So, golf clap for the trivial patch monkeys
21:48:27 <dansmith> dims__ called me at 2am last night to let me know he had added five new bugs to the list
21:48:34 <dims__> LOL
21:48:35 <sdague> heh
21:48:36 <mikal> dansmith: really?
21:48:39 <dansmith> mikal: yes
21:48:41 <mikal> dansmith: I didn't know that was an option...
21:48:42 <dansmith> mikal: REALLY
21:48:44 <dims__> NO
21:48:47 <dansmith> heh
21:48:50 <mikal> dansmith: I SHALL DO THIS THIGN TOO NOW
21:48:50 <melwitt> lol
21:48:58 <dims__> :)
21:49:08 <mikal> I wanna move on again because we're running out of time
21:49:15 <mikal> #topic Stuck reviews
21:49:30 <mikal> So, I think the deprecation thing above could have been classified as one of these
21:49:42 <mikal> Are there any other reviews wedged on reviewers agreeing on a plan?
21:50:13 <mikal> ...going
21:50:17 <dansmith> sounds like not
21:50:19 <mikal> ...going
21:50:27 <mikal> ...gone
21:50:33 <mikal> This is a good thing
21:50:40 <mikal> #topic Open Discussion
21:50:48 <mikal> dansmith: is oslo.versionedobjects you?
21:50:49 <wanyen_> can I discuss my ffe now?
21:51:01 <dansmith> mikal: yeah, so oslo.versionedobjects is a thing now
21:51:17 <dansmith> we've been rapidly iterating on it to get it ready, but mostly for other projects
21:51:20 <mikal> dansmith: can we wait for liberty to move?
21:51:25 <dansmith> I *think* it's probably too risky to do in kilo
21:51:36 <dhellmann> dansmith: ++
21:51:37 <mikal> dansmith: and a distraction from priority work, right?
21:51:43 <dansmith> but there will be some synchronization patches  to keep things in nova in line with oslo, and vice versa
21:51:43 <dims__> +1 to kilo
21:51:53 <wanyen_> I would like to discuss FFE request for passing capabilities requested in flavors to Ironic instance_info http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg45394.html.  Several Ironic Kilo features including secure boot, trusted boot, and local boot support with partition image have dependency on this function.
21:51:57 <mikal> dims__: you mean liberty?
21:52:09 <sdague> yeh, I think the oslo move is liberty
21:52:11 <dansmith> mikal: well, objects == priority, but yes, more churn than I think we need
21:52:38 <mikal> dansmith: yeah, but this stuff is a tangent from waht we thought we were doing with objects in kilo
21:52:47 <dansmith> so I wanted to make sure we agree on that, but also just highlight that (a) we'll want to do that when lemming opens and then (b) that there will be syncs to keep it from diverging too much
21:52:54 <mikal> I think its fine if we have to do a few sync patches in kilo
21:53:03 <mikal> But let's talk about moving over to it with the liberty ptl
21:53:03 <wanyen_> It only affects nova ironic virt driver and the changes are very small. The spec has been merged https://review.openstack.org/136104 and the code https://review.openstack.org/#/c/141012/ has been reviewed by ironic reviewers.
21:53:27 <wanyen_> We have discussed this FFE request at this week’s ironic irc meeting http://eavesdrop.openstack.org/meetings/ironic/2015/ironic.2015-02-09-17.00.txt .  Devananda and Ironic folks at the meeting are in support of it.  It will be much appreciated if we can get nova approval for this FFE request.
21:53:29 <mikal> Ok, ironic ffe now
21:53:42 <wanyen_> mikal, sorry I jumped ahead
21:53:44 <mikal> wanyen_: we've said that the review process happens next week
21:53:55 <mikal> wanyen_: so while I agree that all the things you've said are true
21:54:11 <mikal> wanyen_: I think its premature for me to announce an edict without talking it through with the team
21:54:27 <wanyen_> mikal, yes. I understand.  Sine I am here I just want to give some info about this ffe.
21:54:34 <mikal> wanyen_: and we did say at the beginnign that we were going to try and approve zero ffes to free up focus for priority work
21:54:40 <mikal> wanyen_: ok cool
21:54:49 <dansmith> just a preview of monday: I'm going to -1 all ffes!
21:54:54 <mikal> wanyen_: but yeah, let me chat to specs-core and then we can talk this through next week
21:55:33 <mikal> Anything else for open discussion?
21:55:43 <mikal> Or early mark?
21:55:49 <jogo> sdague mikalL was AFK, releasing new novaclient should be safe
21:55:53 <wanyen_> mikal, thanks!   when will be the ffe review meeting, perhaps I canask Deva to attend?
21:56:24 <mikal> jogo: thanks
21:56:38 <mikal> wanyen_: well, I don't think that's nessesary
21:56:44 <mikal> wanyen_: we understand the arguments
21:56:50 <dansmith> agreed
21:56:52 <wanyen_> mikal, ty
21:56:56 <mikal> wanyen_: we just need to work out how much distraction we can handle while still landing the priority stuff
21:57:11 <mikal> Because we really have to land the priority stuff, by definition
21:57:44 <mikal> That's time up
21:57:46 * jogo is surprised at the number of FFEs
21:57:49 <mikal> So no early mark
21:57:57 <mikal> jogo: well, ffe requests
21:57:59 <wanyen_> mikal, I understand but still hoping you can consider approvingthis ffe
21:58:07 <mikal> jogo: there are no granted ffes so far
21:58:14 <mikal> wanyen_: we will certainly consider it
21:58:18 <mikal> And that's time
21:58:21 <mikal> Thanks everyone
21:58:24 <mikal> #endmeeting