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