14:00:00 <johnthetubaguy> #startmeeting nova
14:00:01 <openstack> Meeting started Thu Feb  5 14:00:00 2015 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:04 <openstack> The meeting name has been set to 'nova'
14:00:16 <anteaya> o/
14:00:20 <johnthetubaguy> #topic kilo release status
14:00:21 <dansmith> o/
14:00:22 <alexpilotti> o/
14:00:26 <bauzas> \o
14:00:27 <dguryanov> o/
14:00:27 <rushiagr> o/
14:00:32 <alex_xu> o/
14:00:35 <alaski> o/
14:00:42 <markus_z> o/
14:00:51 <johnthetubaguy> so, its kilo-2 release day, and non-priority feature freeze day
14:00:54 <n0ano> o/
14:00:58 <johnthetubaguy> #link https://launchpad.net/nova/+milestone/kilo-2
14:01:11 <johnthetubaguy> We certainly have the last few blueprints that could still make it
14:01:24 <johnthetubaguy> mostly either needing one more +2 or already going through the gate
14:01:27 <sdague> o/
14:01:31 <claudiub> \o
14:01:34 <edleafe> o/
14:01:39 <johnthetubaguy> #help please look at kilo-2 blueprints and help finish off the last few
14:02:01 <johnthetubaguy> OK, so lets talk FFE exception process
14:02:07 <johnthetubaguy> the goal was to have no exceptions
14:02:12 <dansmith> +1
14:02:25 <bauzas> so no FFE ?
14:02:33 <dansmith> I have already been pinged asking about FFE sponsorship
14:02:40 <johnthetubaguy> bauzas: unless its exceptional
14:02:44 <mnestratov> o/
14:02:49 <aburluka> o/
14:03:03 <johnthetubaguy> anyways lets think this through...
14:03:06 <alexpilotti> johnthetubaguy: was wondering about thsi one #link https://review.openstack.org/#/c/127159/
14:03:18 <alexpilotti> johnthetubaguy: it already had a +2, lost in the usual ethernal rebases
14:03:57 <alexpilotti> johnthetubaguy: and I was wondering why it got de-approved being a “medium” BP
14:03:57 <johnthetubaguy> I think its an email to ML, describing why its useful
14:04:10 <bauzas> how many core approvals ?
14:04:12 <johnthetubaguy> alexpilotti: its release day, so it got bumped
14:04:20 <johnthetubaguy> bauzas: I am not doing that bit yet
14:04:27 <bauzas> johnthetubaguy: ack
14:04:49 <johnthetubaguy> the email then has to get a +2 from two nova-drivers, and nova-drivers have the usual −2 veto, as part of that
14:04:57 <alexpilotti> johnthetubaguy: bumped as in requiring FFE?
14:04:58 <lxsli> o/
14:04:59 <johnthetubaguy> its like a re-approve of the spec, basically
14:04:59 <dansmith> johnthetubaguy: wait, what?
14:05:17 <dansmith> johnthetubaguy: I thought "filter through drivers" meant more than just "two drivers sponsor it"
14:05:32 <dansmith> I was thinking more like "all drivers agree" or "majority agree"
14:05:43 <dansmith> but you were thinking just two?
14:06:01 <alaski> dansmith: +1.  I figured we would discuss as a group
14:06:03 <johnthetubaguy> well, I was thinking we get to veto some, as the backup
14:06:06 <mdbooth> FWIW, I would be -1 on the design here. It has been problematic in VMware.
14:06:24 <johnthetubaguy> but yeah, lets discuss it as a group
14:06:50 <dansmith> johnthetubaguy: I say we just pick a submission deadline, then have a meeting and run through them
14:06:55 <johnthetubaguy> I guess we try to find a meeting time a week tomorrow for nova-driver to vote on the requests?
14:07:08 <johnthetubaguy> with the deadline for submission being next weeks nova-meeting?
14:07:19 <dansmith> that's fine with me
14:07:29 <n0ano> johnthetubaguy, could you do the vote at next week's nova meeting?
14:07:45 <alaski> johnthetubaguy: dansmith works for me as well
14:08:07 <johnthetubaguy> n0ano: it will be an open IRC meeting when it happens, I hope, but not quite then
14:08:20 <neiljerram> I'm confused, are you talking about voting on exceptions for specs and/or code that have just been bumped?
14:08:27 <n0ano> as long as it at a specific date
14:08:28 <johnthetubaguy> #action johnthetubaguy to email about the exception process
14:08:37 <bauzas> neiljerram: talking about features
14:08:46 <sdague> johnthetubaguy: it would be good to get ttx in the loop about the process in advance
14:09:00 <neiljerram> bauzas: OK, thanks
14:09:10 <sdague> I think he felt blind sided on the FFEs for nova last time, and that it went so long
14:09:12 <johnthetubaguy> sdague: good point, I will catch up with him later anyways, I will bring that up
14:09:55 <johnthetubaguy> OK, so any more questions on the release and its process right now?
14:10:25 <johnthetubaguy> the plan is to tag the release before the end of "today" where today might be in an obscure timezone, if required
14:10:33 <dguryanov> We have almost complemed work on blueprint https://blueprints.launchpad.net/nova/+spec/pcs-support
14:10:37 <neiljerram> I'm not sure - does this interact with looking at stuck reviews later in this meeting?
14:10:55 <mnestratov> dguryanov: I would like to ask for exception for https://review.openstack.org/#/c/149253/
14:11:14 <johnthetubaguy> dguryanov: its delayed till kilo at this point, without an exception
14:11:20 <johnthetubaguy> but yes, lets talk reviews later
14:11:27 <johnthetubaguy> #topic Kilo priorities
14:11:39 <johnthetubaguy> #link https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
14:11:53 <johnthetubaguy> the above link contains lots of stuff that urgently needs reviews
14:11:57 <bauzas> agreed
14:12:20 <johnthetubaguy> new are the bugs at the bottom, where a lovely team are tracking bug fixes that are ready to go and get merged
14:12:29 <bauzas> sounds like the bugbuster process is working
14:12:37 <johnthetubaguy> #help please consult https://etherpad.openstack.org/p/kilo-nova-priorities-tracking for bugs and blueprint patches to review
14:12:47 <dansmith> yes, the bug hitlist is working very well, IMHO
14:12:57 <johnthetubaguy> +1
14:12:58 <sdague> agreed
14:13:00 <johnthetubaguy> So, do we have any major updates or worries from the priority list?
14:13:01 <bauzas> do you need to cap the list ?
14:13:08 <johnthetubaguy> bauzas: it is capped already
14:13:13 <bauzas> we're trying to keep the list by 20
14:13:17 <bauzas> itzmq
14:13:27 <bauzas> johnthetubaguy: yeah, that's me who capped it
14:13:28 <bauzas> :)
14:13:41 <bauzas> johnthetubaguy: but maybe we can raise the bar
14:13:47 <dansmith> no
14:13:49 <johnthetubaguy> lets go with what we have
14:13:52 <bauzas> ack
14:13:53 <dansmith> I think it's good to keep it capped
14:14:01 <bauzas> +1
14:14:01 <dansmith> it's much harder to track whether I've been through all of them if there are too many
14:14:04 <johnthetubaguy> yep, a cap is good, 20 seems like a good start
14:14:06 <bauzas> agreed
14:14:15 <bauzas> how long do we keep track of the merged ones ?
14:14:18 <lxsli> incidentally gerrit 2.9 brings is:mergeable and delta:<50 search options
14:14:41 <johnthetubaguy> bauzas: launchpad does that, maybe add a tag if you want to track them after they merge
14:14:44 <dansmith> bauzas: it's just informational right now, so lets keep them for a while
14:15:09 <dansmith> we've merged 30 fixes since the midcycle, that seems really good
14:15:10 <bauzas> dansmith: yeah my point was just when to delete them from the etherpad, because they're stroke
14:15:15 <johnthetubaguy> anyways, lets not bog down in that, lets just try keep it lightweight and sustainable
14:15:20 <dansmith> bauzas: I know
14:15:30 <johnthetubaguy> probably when they get annoying
14:15:38 <sdague> lxsli: nice
14:15:46 <lxsli> maybe in a month we can do a little analysis of how the process is working then cleanup the merged ones
14:15:46 <johnthetubaguy> maybe add a tag in launchpad, and it will help track stuff
14:16:01 <johnthetubaguy> but lets move on, thats good stuff though
14:16:06 <johnthetubaguy> any more on priorities?
14:16:24 <anteaya> do you want me here?
14:16:37 <johnthetubaguy> anteaya: yes, if there are updates
14:16:40 <anteaya> sure
14:16:43 <anteaya> #link https://review.openstack.org/#/c/147723/
14:16:53 <anteaya> that is the spec part 1 I would like to get merged
14:17:05 <anteaya> mikal and jogo have reviewed from nova, thank you
14:17:17 <sdague> fwiw - https://review.openstack.org/#/c/126309/ is really dubious in size for "quick bug fix", it would be nice if these were smaller things than that
14:17:24 <anteaya> dansmith: if you could review then I will bug neutron folks to get it merged
14:17:38 <anteaya> there is also code at
14:17:41 <anteaya> #link https://review.openstack.org/#/q/topic:bp/migration-from-nova-net,n,z
14:17:46 <dansmith> sdague: that is entirely not a trivial fix
14:17:50 <anteaya> for folks waiting to see a proof of concept
14:17:52 <anteaya> done
14:18:03 <dansmith> anteaya: okay
14:18:06 <anteaya> thanks
14:18:53 <johnthetubaguy> cool, some progress there, which is great
14:19:00 <anteaya> it is
14:19:02 <anteaya> :)
14:19:10 <johnthetubaguy> #topic gate status
14:19:57 <johnthetubaguy> it doesn't seem to be crazy right now which is nice
14:20:07 <johnthetubaguy> not got any specific updates, so lets move on I guess...
14:20:22 <johnthetubaguy> #topic Bugs
14:20:32 <johnthetubaguy> now, we had some great progress above already
14:20:39 <johnthetubaguy> any specifics we want to cover?
14:20:59 <lxsli> I think dims deserves some love on https://review.openstack.org/#/c/146294/
14:21:19 <lxsli> He's in rebase hell atm
14:21:25 <sdague> the ext4 link is no good, did that merge?
14:21:39 <johnthetubaguy> sdague: unsure, I was trying to work that out too
14:21:51 <danpb> sdague: yes
14:21:57 <johnthetubaguy> lxsli: I am tempted to say we should merge that tomorrow, post kilo-2 release
14:22:12 <sdague> ok, cool
14:22:23 <lxsli> works for me
14:22:41 <sdague> if we agree the olso change should merge, we can just have one person work with dims and jam it in, whenever everyone agrees
14:22:57 <johnthetubaguy> anyways no one else has piped up, the others should be considered for the bug hit list if required
14:22:57 <sdague> I can do that on friday with him
14:23:09 <johnthetubaguy> sdague: awesome plan, thank you
14:23:21 <johnthetubaguy> #topic Stuck Reviews
14:23:45 <johnthetubaguy> So the list is massive, but half of them look like blueprints that are now unapproved till L
14:23:46 <dguryanov> This one is almost approved - https://review.openstack.org/#/c/149222/14
14:24:21 <sdague> yeh, I think my only issue was the missing rootwrap filter
14:24:24 <johnthetubaguy> dguryanov: but it looks like its all dependent on this one: https://review.openstack.org/#/c/149253/2
14:24:26 <sdague> which looks fixed
14:24:27 <mnestratov> dguryanov: Yes, guys please pay attention on this
14:24:34 <mgoddard1> Could we discuss https://review.openstack.org/#/c/153230 please?
14:24:56 <johnthetubaguy> dguryanov: thats why this blueprint has been punted to L right now, didn't look like we could merge that today :(
14:25:08 <dansmith> mgoddard1: that has been posted for less than an hour
14:25:21 <mdbooth> This one is trivial, just needs another +2: https://review.openstack.org/#/c/134499/
14:25:22 <danpb> this isn't critical for Kilo-2 - I'd just like some review on it so we can try to merge during Kilo-3 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:virtimageinfo,n,z
14:25:36 <mnestratov> johnthetubaguy: split this chain then
14:25:43 <johnthetubaguy> danpb: we can't merge it during kilo-3, its not a priority item
14:25:53 <neiljerram> Can I ask about / pitch https://review.openstack.org/#/c/146914/ ?
14:25:55 <lxsli> mdbooth: that has a -1 from dansmith
14:26:02 <mdbooth> lxsli: Yeah, I can't account for that
14:26:09 <mdbooth> dansmith: ^^^ See the problem?
14:26:14 <danpb> johnthetubaguy: its a bug
14:26:20 <dansmith> mdbooth: yep
14:26:30 <danpb> johnthetubaguy: and bugs are priorit items IIUC
14:27:01 <johnthetubaguy> bugs are fine, yes, I thought you meant pcs, got confused, sorry
14:27:14 <edleafe> I could use some core nova-specs re-review of https://review.openstack.org/#/c/138444/
14:27:24 <sdague> johnthetubaguy: the parallels stack below the config drive patch is approved now, the bottom patch just needed the rootwrap fix
14:27:25 <mgoddard1> dansmith: Ok, next time after it has been up for longer
14:27:26 <edleafe> It adds the changes we agreed on at the midcycle
14:27:55 <dansmith> mgoddard1: the stuck reviews section is for reviews that are stuck, not unreviewed.. please be patient
14:28:04 <dguryanov> sdague: I've added rootwrap
14:28:06 <dguryanov> https://review.openstack.org/#/c/149222/15/etc/nova/rootwrap.d/compute.filters
14:28:10 <johnthetubaguy> sdague: can you work with the folks to get that in the next few hours, I don't mind helping a bit too, and we can get that in then
14:28:27 <bauzas> dansmith: I think he was talking about the bug
14:29:05 <bauzas> dansmith: but the bugs topic has been discussed fast, so he probably missed it
14:29:20 <sdague> johnthetubaguy: well, all the patches up until your -2 are now actually in approved state
14:29:28 <dansmith> bauzas: maybe, but .. review link :)
14:29:29 <sdague> I'm rechecking tests on one
14:29:34 <bauzas> dansmith: agreed
14:29:39 <dims_> so, am very happy about the quick hit bugs we are tracking on https://etherpad.openstack.org/p/kilo-nova-priorities-tracking - thanks everyone for working that list!
14:29:55 <johnthetubaguy> sdague: its just that didn't have any work done on it in 7 days, so I figured it wasn't going to happen today, but I am fine with the rest landing, for sure
14:30:14 <flip214> Regarding DRBD, I heard quite a few people wanting that in. is there going to be a vote about that, so that there's a chance to get the -1/-2 removed? That's https://review.openstack.org/#/c/134153/
14:30:19 <sdague> johnthetubaguy: cool, I'll look at the other patches
14:30:23 <dguryanov> We wanted to fix it together with LXC bug :)
14:30:23 <dims_> 34 bugs were merged!
14:30:41 <dguryanov> with this one https://bugs.launchpad.net/nova/+bug/1340834
14:30:47 <johnthetubaguy> lets back up...
14:31:04 <johnthetubaguy> do any of these reviews need some discussion, because of negative comments, etc?
14:31:14 <claudiub> I also want to ask about https://review.openstack.org/#/c/140313/ --  I've asked on ML, how microversioning impacts contrib/*.py
14:31:32 <pczesno> about vhostuser patches , can someone please have a look at them? it's a feature that's been around since juno
14:31:42 <alex_xu> claudiub: microversion won't impact contrib/*.py
14:31:42 <pczesno> https://review.openstack.org/#/q/topic:bp/libvirt-vif-vhost-user,n,z
14:31:48 <sdague> dgonzalez: https://review.openstack.org/#/c/149253 needs to pass tests though, which it currently doesn't
14:31:56 <mnestratov> johnthetubaguy: only the last in the series
14:32:00 <johnthetubaguy> claudiub: thats a good question, but thats going to have to wait until L now :(
14:32:22 <andymaier> From the 4 remaining system z patch sets, can we get these two approved? https://review.openstack.org/#/c/149242/ and https://review.openstack.org/#/c/149653/
14:32:55 <markus_z> A previously merged review introduced a bug which couldn't be found by the gate tests because the unit test mocked on a wrong level and a CI environment for system z is still under construction. This bug will *always* cause a failure of the spawn on sytem z. https://review.openstack.org/#/c/149653/
14:33:38 <mdbooth> johnthetubaguy: This one is trivial, but it has a -1 from dansmith, which is an effective death sentence: https://review.openstack.org/#/c/134499/
14:34:01 <johnthetubaguy> andymaier: we can't merge those ones because the blueprint is not approved
14:34:16 <andymaier> the blueprint was approved until recently
14:34:21 <devananda> johnthetubaguy: this one is alraedy 2 +2'd -- https://review.openstack.org/#/c/144792/
14:34:28 <sgordon> johnthetubaguy, i think flip214 asked about the DRBD patches - there was an exception email for them a while back (two actually) but i don't think there was ever any response - code is at https://review.openstack.org/#/c/134153/
14:34:39 <devananda> johnthetubaguy: just waiting on the dependent parts in ironic-client to move through the gate and then we'll trigger a recheck on the nova patch
14:34:46 <devananda> johnthetubaguy: think we can get that into k2 ?
14:34:57 <flip214> sgordon: there was one follow-up mail, duncant saying he'd like to see that in.
14:34:58 <johnthetubaguy> devananda: when will the client be ready?
14:35:10 <danpb> devananda: as soon as the tempest tests show green i was going to +A it
14:35:20 <sgordon> flip214, right - duncan is cinder core though - no input from the nova side to confirm accept/deny
14:35:22 <devananda> johnthetubaguy: the parts are in the gate _now_. I'll tag a client as soon as they land
14:35:22 <dansmith> danpb: devananda same
14:35:32 <danpb> so its just dependant on how fast you can get the ironic stuff done
14:35:33 <dansmith> devananda: ping me when it happens
14:35:38 <johnthetubaguy> sgordon: I will follow up on the ML about that, I thought mikal was sending an email on that one, basically they are denied, see the comments on the nova-spec
14:35:38 <devananda> dan*: great, thanks. will do
14:36:06 * mriedem joins super late
14:36:07 <johnthetubaguy> devananda: dansmith: awesome, let me know when its ready, so we get the tagging ready, etc
14:36:38 <neiljerram> Is there any core interest in https://review.openstack.org/#/c/146914/ (VIF_TYPE_TAP)?  I thought there might be, following ML discussions around the time that the spec was being honed in Nov/Dec.
14:37:15 <mnestratov> thank you guys
14:37:45 <johnthetubaguy> neiljerram: blueprint is not approved any more, as its passed the kilo-2 feature freeze now
14:37:55 <johnthetubaguy> OK, so lets move on to things the whole group can help with...
14:38:03 <TobiasE> Multi-Attach https://review.openstack.org/#/c/143114/ is now being split into   https://review.openstack.org/#/c/153033/   and https://review.openstack.org/#/c/153038/
14:38:10 <johnthetubaguy> #topic open discussion
14:38:18 <johnthetubaguy> kilo meetup was fun
14:38:19 <TobiasE> Is a feature freeze exception needed?
14:38:35 <johnthetubaguy> #link https://etherpad.openstack.org/p/kilo-nova-midcycle for details on the midcylce
14:38:35 <ndipanov> johnthetubaguy, sorry just for my undersatnding - can we approve patches today still ?
14:38:37 <ndipanov> or not?
14:39:03 <johnthetubaguy> ndipanov: ideally, only things you want landing in kilo-2, but the gate is not (yet) totally jammed
14:39:04 <sgordon> there was a list of stuff that is close here: https://launchpad.net/nova/+milestone/kilo-2
14:39:15 <ndipanov> yes that's wha tI meant
14:39:24 <ndipanov> approved bp + patch close
14:39:32 <ndipanov> since I assumed the -2s come tomorrow
14:39:53 <johnthetubaguy> TobiasE: https://blueprints.launchpad.net/nova/+spec/multi-attach-volume has been delated until L at this point, without an exception
14:40:07 <johnthetubaguy> ndipanov: they are starting right now
14:40:11 <soren> Can we talk about the EC2 API now?
14:40:19 <ndipanov> ok
14:40:26 <johnthetubaguy> ndipanov: the kilo-2 list is trimmed down to stuff we think *might* still make it
14:40:50 <ndipanov> Ok well I won't approve any more stuff not on the list
14:40:58 <ndipanov> that's basically what I wanted to know
14:41:07 <claudiub> johnthetubaguy: can this still be ok for kilo? https://blueprints.launchpad.net/nova/+spec/hyper-v-test-refactoring  it's literally just unit tests, all code is up, and we really need to remove the mox usage...
14:41:17 <danpb> sdague added a open discussion item about the  hypervisor support matrix that is now merged in GIT - I sent a mail to kickstart further discussion here http://lists.openstack.org/pipermail/openstack-dev/2015-February/056093.html
14:41:18 <johnthetubaguy> ndipanov: OK, sorry, thats probably best, I mean important bugs are cool too
14:41:25 <ndipanov> bugs - sure
14:41:28 <mriedem> can we leave the exception requests to the ML please?
14:41:37 <johnthetubaguy> mriedem: +1
14:41:57 <mriedem> http://docs.openstack.org/developer/nova/support-matrix.html
14:41:58 <johnthetubaguy> soren: you had some questions on ec2, I see the spec discussion linked on the agenda
14:42:16 <soren> There were 3-5 separate discussions (one one a spec patch, one on a nova code patch, and two separate mailing list discussions) about the EC2 api, so I think it'd be useful to sync up on it real quick.
14:42:54 <soren> Basically, we'd like to keep it right where it is and throw some people at getting it into better shape.
14:43:19 <soren> ...but there seems to be a bit of lack of clarity as to whether that'd be possible if it got marked deprecated.
14:43:20 <dansmith> who is "we" ?
14:43:33 <soren> Me and my team (at Reliance).
14:43:42 <mriedem> what do the cloudscaling guys say about that?
14:43:57 <mriedem> compare git logs between the nova ec2 tree and the ec2-api repo in stackforge
14:44:01 <mriedem> much different levels of activity
14:44:04 <danpb> from the discussions it seems like the consensus was that we'd bugfix in-tree EC2 for a whle longer, but the long term direction for feature dev work was the out of tree impl
14:44:21 <dansmith> agree that seems to be the consensus
14:44:24 <soren> I think we have different ideas about what "consensus" means :)
14:44:26 <mriedem> the one big bug that was blocking latest boto was fixed this week
14:44:30 <danpb> it didn't see any strong desire from the majority todo any real feature work on in-tree EC2 api
14:44:34 <dansmith> to me, marking it deprecated helps communicate that we only really want fixes
14:44:44 <johnthetubaguy> soren: I think we allow bug fixes to deprecated code, so it doesn't block that work
14:44:47 <soren> Yes, it does help that... but that's not what we want.
14:45:03 <mriedem> if we only want bug fixes i'd probably say it's in maintenance/stable mode rather than deprecated
14:45:04 <soren> We think keeping it inside Nova is the sounder approach.
14:45:08 <danpb> its really a matter of timing as to when in-tree impl will go away, rather than if it will go away
14:45:49 <dansmith> mriedem: call it frozen if you want, but deprecated has meant "no new features, only fixes, planning to eject this at some point" for our stuff in the past
14:45:58 <danpb> soren: without wishing to speak for anyone else, that seems like a minority opinion right now
14:46:04 <dansmith> it's also not "stable" by any definition, IMHO :)
14:46:06 <mriedem> dansmith: yeah, just sounds like if it will go out is still up in the air
14:46:15 <sdague> soren: so if we were to reverse that decision to focus on the out of tree implementation, we'd need a really hard cut off about "nope, didn't get it up to snuff"
14:46:17 <johnthetubaguy> soren: honestly, this seems like a mid-cycle / summit discussion, that will go much better if we have lots of bug fixes merged, and better testing, by the time the summit comes around, does that make sense?
14:46:30 <sdague> because there have been repeated statements by folks that said they would work on it
14:46:32 <sdague> that didn't
14:46:41 <soren> sdague, johnthetubaguy: I understand.
14:46:44 <danpb> assuming Nova API provides sufficient functionality there's no compelling reason to keep EC2 in tree
14:46:47 <soren> I just ask for one last chance.
14:46:56 <sdague> soren: so, how about the following
14:47:04 <soren> ...but if everyone is hell bent on ripping it out, we don't want to waste our time.
14:47:16 <sdague> instead of 'deprecated' we mark it 'experimental' like the cells code
14:47:16 <dansmith> I'm definitely hell bent
14:47:22 <dansmith> ...on lots of things :)
14:47:27 <soren> I've noticed :)
14:47:27 <sdague> we give it until summit
14:47:36 <dims_> soren: anyone arranging a ec2 weekly meeting?
14:47:43 <johnthetubaguy> sdague: we could un-deprecate at the summit I guess?
14:47:48 <sdague> and evaluate both the state of the code, and the state of testing for it (which is also lacking)
14:47:52 <soren> dims_: I don't think we need more meetings and discussion. We need engineering and code.
14:48:00 <dansmith> calling it experimental is just silly, IMHO
14:48:05 <soren> There's been plenty of talk, not much code.
14:48:12 <swamireddy> I am planning for EC2 weekly meetings
14:48:35 <sdague> I'm personally ok on giving it until summit and making final decision there
14:48:56 <danpb> i'd just label it as being "maintenance mode" if we want todo something right now
14:49:04 <dansmith> sdague: so my problem with that,
14:49:08 <dims_> sdague: if a good plan materializes with people behind it actively working on it
14:49:20 <dansmith> sdague: is that we have a group of folks that are *actually* actively working on a usable modern ec2 api for nova
14:49:29 <danpb> and re-evaluate at end of Kilo-3 to see if we should call it something different for final release
14:49:43 <dansmith> sdague: seeing if a small group can do enough in the next three months to convince us to keep a duplicate thing doesn't seem like a good use of resources to me
14:49:53 <rushiagr> I request we (Reliance) and other people get to add tempest tests too, and think about moving them out later..as this would hinder consolidating the test coverage work..
14:49:53 <soren> dansmith: I know it's not a lot, but we have a number of patches for the in-tree EC2 API that just haven't gotten reviewed.
14:49:54 <sdague> dansmith: sure, that's also fair
14:50:03 <dansmith> sdague: seems like most people think that, technically, the other project is superior, even if it needs polish
14:50:10 <soren> dansmith: So the complete lack of activity isn't entirely accurate.
14:50:22 <dansmith> soren: there's another point to be made there
14:50:24 <danpb> as it is in tree EC2 inevitably suffers from the nova-core bottleneck
14:50:36 <dansmith> soren: which is "relative success of the other project vs. core attention in nova proper"
14:50:44 <danpb> so doing it out of tree could dramatically increase its speed of development
14:50:46 <sdague> soren: well, there's also the issue that ec2 focused folks seem only interested in ec2, and not the rest of nova
14:50:48 <soren> danpb: We also disagree on what "inevitable" means, apparently :)
14:51:04 <sdague> which makes it a hard fit for intree
14:51:08 <dansmith> right
14:51:20 <soren> Frankly, my concern is not which git repo it lives in.
14:51:22 <dims_> soren: +1 to engineering and code
14:51:27 <soren> It's where it sits architecturally.
14:52:25 <dansmith> so, I don't really see that our internal compute interface does much for the ec2 layer at all
14:52:26 <soren> And I think the rigth place -- architecturally -- is in Nova.
14:52:43 <dansmith> if anything, the ec2 layer jumps through hoops to continue working with whatever we evolve the internal interface to be
14:52:45 <dims_> soren: you mean ability to run as part of nova processes
14:52:45 <johnthetubaguy> hmm, so the out of tree thing is assumed to talk to our REST API, not direct to our objects, or did I miss a bit?
14:52:59 <danpb> johnthetubaguy: yep, that's correct
14:53:00 <soren> dansmith: ...and that will only get worse if it's moved outside entirely.
14:53:02 <dansmith> it has its own mapping tables, and lots of inefficient iteration of resources to translate them into a useful result for the ec2 client
14:53:03 <bauzas> soren: why a 3rd-party API should reside naturally in-tree ?
14:54:01 <dansmith> soren: the approach we take means that it continues to get worse in tree too, since we mostly ignore it
14:54:03 <danpb> i think it'd benefit nova development as a whole if ec2 were just using our public APIs and not poking at internals as it'd be one less thing to worry about when refactoring code
14:54:14 <bauzas> danpb: +1
14:54:17 <dims_> danpb: +1
14:54:18 <dansmith> soren: we do what we want for the openstack api, and then force fit ec2 until it passes the few tests we have
14:54:18 <edleafe> danpb: +1
14:54:19 <johnthetubaguy> +1 to that
14:54:29 <sdague> danpb: agreed, and if we need to add some APIs to support it, I think that's legit
14:54:29 <alex_xu> danpb: +1
14:54:37 <soren> danpb: Quite the opposite. Having multiple frontends should keep the separation of the various layers cleaner.
14:54:38 <danpb> sdague: absolutely
14:54:46 <soren> It just hasn't, because the EC2 API hasn't gotten sufficient attention.
14:54:46 <dansmith> danpb: +1
14:54:48 <sdague> and should be in the priority item list, so could still merge through K3
14:54:58 <russellb> agreed with danpb, sdague
14:55:08 <danpb> if our current API is insufficient to implenent an out of tree EC2, then it is probably insufficient for many other use cases too
14:55:17 <danpb> so improving our public API will help more than just the EC2 impl
14:55:26 * anteaya has a question about http://docs.openstack.org/developer/nova/support-matrix.html when we are changing topics
14:55:27 <bauzas> 5 mins left
14:55:52 <johnthetubaguy> danpb: yes, I am with you there, lets add the APIs EC2 api might need
14:56:02 <anteaya> can I get a definition of 'choice' and 'condition' in that matrix?
14:56:17 <dansmith> so, given the swath of +1s above, how is deprecation not the right word at this point? :)
14:56:32 <danpb> anteaya: so 'condition' was an attempt to represent the idea that  the feature was conditional on another feature existing first
14:56:33 <dansmith> given what it has meant in the past
14:56:41 <johnthetubaguy> soren: just to work out the issues, is this because you don't want EC2 talking to the REST API?
14:56:43 <anteaya> danpb: ah
14:56:53 <soren> johnthetubaguy: That's a major part of it, yes.
14:56:55 <danpb> anteaya: wihle 'choice' was an attempt to represent the idea that at least one out of a set of possible feature should be chosen
14:57:04 <anteaya> danpb: thanks
14:57:40 <johnthetubaguy> soren: the problem is we don't want to maintain any more external backwards compatibile apis other than the rest API, as we are really bad at doing that right now
14:57:47 <mriedem> danpb: how about some definitions for the status values in the page?
14:57:55 <danpb> anteaya: its fairly crude but it was the best i came up with so far. obviously suggestions welcome for improvements
14:58:00 <johnthetubaguy> dansmith: I think it should be deprecated too, givne this discussion, we can always go back on that
14:58:12 <soren> johnthetubaguy: The only way to ensure Nova's data model is rich enough to support an EC2 API is if it's part of Nova.
14:58:17 <anteaya> danpb: none come to mind at present, but if that changes I will find you
14:58:21 <danpb> mriedem: yes, that would probably help - right now they were just definined in the .ini file
14:58:35 <soren> johnthetubaguy: The newly proposed implementation's reaching around into Nova's database is a clear indication of this.
14:58:39 <bauzas> soren: OCCI API could say the same words, but that's also a 3rd-party API
14:58:46 <dansmith> soren: what?
14:58:50 <soren> bauzas: What's your point?
14:58:52 <johnthetubaguy> soren: I guess we are saying, some with API requirements for what you need, and add those instead
14:59:01 <danpb> soren: no that's just an indication of our APIs being insufficient
14:59:13 <dansmith> soren: the out of tree implementation shouldn't need to see nova's database, that's the point of what was said about adding APIs where needed
14:59:15 <danpb> soren: if it had been out of tre all the along, we would have fixed the gaps in our APIs long ago
14:59:19 <johnthetubaguy> soren: I certainly disagree with it talking to the API and the database
14:59:20 <bauzas> soren: just to say that EC2 API is not a native API, so that sounds reasonable to envisage it as out-of-tree, and proxying to the native API
14:59:24 <johnthetubaguy> its time...
14:59:29 <danpb> instead no one bothered to fix the APIs and just made the code poke at the DB
14:59:48 <johnthetubaguy> right, thats broken
14:59:50 <soren> bauzas: EC2 was there first.
15:00:01 <johnthetubaguy> OK, so its time
15:00:03 <johnthetubaguy> thanks all
15:00:04 <soren> bauzas: So it's really more native than the OpenStack API :)
15:00:08 <lxsli> Sounds like violent agreement: soren wants to fix internal APIs to be rich enough, danpb wants to fix REST API
15:00:10 <johnthetubaguy> more chat in #openstack-nova as normal
15:00:19 <anteaya> johnthetubaguy: thank you
15:00:23 <johnthetubaguy> #endmeeting