18:00:20 #startmeeting trove 18:00:21 Meeting started Wed Apr 16 18:00:20 2014 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:24 The meeting name has been set to 'trove' 18:00:33 o/ 18:00:38 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Agenda_for_the_weekly_meeting_Apr.16 18:00:42 o/ 18:00:47 \o 18:01:04 7o7 18:01:09 previous meeting minutes: 18:01:11 o8 18:01:13 #link http://eavesdrop.openstack.org/meetings/trove/2014/trove.2014-04-09-18.00.html 18:01:13 holla o] 18:01:19 o/ 18:01:51 \o 18:01:51 We have a quorum. Let's get started. 18:01:58 #topic Discuss the expectations of an agenda item for the weekly meeting 18:02:10 alright, this is me 18:02:14 Lately, agenda items have been extremely terse (usually just a link). 18:02:17 G/ 18:02:20 We’d like to try and make this meeting more focused by keeping it very goal-oriented. 18:02:26 This means agenda items should have a clearly defined objective. 18:02:32 Good: Review #xxxxx has comments on foobar.py from multiple folks and there seems to be no consensus on how to solve problem ‘y’. Let’s quickly rehash the merits of both approaches in 2-5 minutes and call for a vote. Goal: choose an approach and move forward on implementation. 18:02:35 \o\ 18:02:39 Bad: Discuss blueprint ‘xyz’ 18:02:44 Bad: Revisit blueprint ‘abc’ that we talked about last week to get answers on remaining disagreements. 18:02:52 (Note: the last example is bad because the remaining disagreements should be clearly articulated, with each point of view represented and summarized). 18:02:58 At the conclusion of an agenda item, a summary of key conclusions, action items, and points of accountability should be noted. 18:02:58 o/ 18:03:01 o/ 18:03:05 It’s likely that we’ll want to introduce time-boxing per agenda item in the future, but we think this is a good start. Any questions? 18:03:08 o/ 18:03:46 amcrn: So, each agenda item requires a more refined synopsis, and a time limit? 18:03:50 amcrn: who's responsibility is it to summarize the item minutes? 18:03:53 As well as a clear goal. 18:03:58 o 18:04:00 kevinconway: the purpose who added it to the agenda 18:04:07 the person* 18:04:19 grapex: synopsis plus well defined goal 18:04:22 amcrn: sounds like a good start 18:04:43 amcrn, agreed. one suggestion (given that this is irc) is that we allow the leader of an agenda item to talk and hold only one conversation going if possible 18:04:49 such as with this conversation now 18:04:53 you proposed something 18:04:58 and you got a couple of replies 18:05:03 but they were all directed at you 18:05:07 i feel like this could have an impact on our useful side conversations that take place during long agent item talks 18:05:08 and it is possible/effective 18:05:30 o/ 18:05:36 kevinconway: That is a sad 18:05:48 amcrn: I like this idea. SlickNik, do you think we should vote on it now? 18:05:54 o/ 18:06:05 amcrn: you agree wity my idea or not 18:06:07 o/ 18:06:12 amrith: not sure i understand your suggestion 18:06:26 amcrn / grapex: I like this too. 18:06:30 amcrn: often we have many conversations going in parallel 18:06:31 What's the course of action when a "bad" agenda item makes its way on to the agenda? 18:06:31 grapex: so hang on, if you're going to vote on a process should we get it codified into a by-law? 18:06:34 and it is confusing 18:06:46 so along with the idea of a clearly defined agenda item 18:07:10 I was proposing that we have some structure in the conversation 18:07:21 and end with a decision/conclusion 18:07:25 we can play police a bit more and stop tangential conversations from over-running the channel 18:07:48 amcrn: ok, makes sense 18:07:50 and to your last point: [11:02:59] At the conclusion of an agenda item, a summary of key conclusions, action items, and points of accountability should be noted. 18:08:05 SlickNik: I vote it goes to the bottom of the list 18:08:07 amcrn: I agree 18:08:39 SlickNik: but we can take a peek and ping people on Monday/Tuesday giving some guidance on how items can be framed/boxed better. 18:08:39 the wiki page gets overwritten though 18:08:40 amrith: are you suggesting http://www.robertsrules.org/? 18:08:59 * robertmyers does 18:09:14 amcrn: +1 on the guidance piece. 18:09:45 Okay, I think pretty much all of us think this is a good idea. 18:09:53 agreed 18:10:02 To grapex's call for a vote: +1 18:10:05 +1 and the same "rules" should be carried over to the Monday BP meeting 18:10:07 +1 18:10:12 +1 18:10:14 +1 18:10:16 +1 18:10:19 +1 18:10:27 +1 18:10:29 +1 18:10:30 can i get a summary of this before vote? 18:10:32 +1 18:10:35 +34 18:10:41 kevinconway: i'll do so and put it on the wiki 18:10:49 +1 18:10:49 so what is everyone voting on? 18:10:55 lol 18:11:04 i got lost in the side convos 18:11:05 voting 18:11:05 +1 18:11:07 kevinconway, voting for the vote 18:11:15 moving on 18:11:22 Okay, let's move on. 18:11:30 #topic Datastore and Datastore Version Concat in Trove Horizon Dashboard 18:11:30 SlickNik: Maybe you should post these new rules on the top of the agenda wiki page so people see them before they add anything 18:11:42 grapex: i'll take care of that, good idea 18:11:54 grapex +1. amcrn: thanks 18:12:00 michael-yu: you're up 18:12:02 So, this topic is the Horizon patch for supporting multiple data stores. 18:12:22 For the proposed behavior, see the commit message: 18:12:23 https://review.openstack.org/#/c/75269/ 18:12:42 There is an underlying question is whether we should have 2 drop downs in Launch Instance 18:12:53 one for datastore type, the other for datastore-version 18:13:00 or just one drop down that concats the two 18:13:02 michael-yu, i read all coments and came in to the conclusion, that dashboard should have two dependent choise box 18:13:38 denis_makogon: ok 18:13:56 michael-yu: I fine with two if you must 18:14:05 i'm a +0 18:14:29 i tend to agree with robertmyers on this one.. although we're represented it as two separate fields in the DB.. most deployers will make this an easy concat when they set it up 18:14:33 But possibly the ui should handle it 18:14:48 with angular :) 18:15:15 so, can we move on ? 18:15:23 robertmyers, were those your review comments? looks like you weren't in favor? 18:15:31 denis_makogon: no, because the goal hasn't been met 18:15:39 i guess we agreed that two dropdowns are totally fine 18:15:53 amrith: yes those are mine 18:15:57 does anyone else in the room have an opinion? 18:16:05 robertmyers, thx 18:16:06 like I said I don't love it 18:16:17 but I wont stand in the way 18:16:22 because i find robertmyers point somewhat intriguing, because it almost suggests they should haven't been two fields in the first place. 18:16:22 If going with two, could the database type default to "mysql" and the version to the latest version for the selected type? 18:16:29 shouldn't* 18:16:42 amcrn: yes 18:16:48 it is silly 18:16:50 amcrn typed the words faster than I could 18:16:54 I have a slight preference for 1, because it's one less click, and one less control. 18:17:00 robertmyers: where were you when i was the only one voting for single field against a barrage of others :P 18:17:08 austin 18:17:11 :) 18:17:11 lol 18:17:32 robertmyers, amcrn ... other than the aesthetics can you see a downside to two boxes? 18:17:36 aren't they linked? 18:17:42 yes, they are linked 18:17:46 i don't see how the number of db columns defines the interface 18:17:50 well the UI doesn't necessarily have to reflect how data is stored 18:17:58 vipul, agreed 18:18:02 kevinconway: +1 18:18:08 We may just end up with the 2nd box just containing a single entry for all database 18:18:23 ... e..g MySQL -> 5.5 only 18:18:26 abramley: good point 18:18:26 with devstack right now, the result would be "mysql-mysql-5.5" 18:18:37 well, what we really want is people to pick the version 18:18:39 why don't we go with one less drop-down and if this really becomes an issue.. we can revisit by changing the UI 18:18:52 vipul: +1 18:18:57 that is my point 18:18:58 I like vipul's idea (also robert, amcrn) 18:19:03 +1 on that 18:19:08 +1 for a single dropdown with a merged datastore and version 18:19:15 vipul: i'll agree if as a follow-up we can have a blueprint discussing the termination of datastore-type permanently from the api in a version 2 18:19:24 because it's caused nothing but headaches 18:19:24 if that's the case, i'm fine too 18:19:43 amcrn: so expose just a version? 18:19:49 vipul: +1 for a single dropdown 18:20:02 vipul: one field, "mysql-5.5" vs "mysql" and "5.5" 18:20:22 because as of now, datastore-type is an overglorified piece of metadata that's acting as a first class element 18:20:31 I suppsoe that would work.. everything is tied to the datastore_version.. 18:20:42 amcrn: I like it, but that's a conversation for another day. 18:21:02 agreed, tangential. i'll take up an action item to summarize my thoughts on that and bring it up another time in a blueprint. 18:21:09 vote time? 18:21:12 amcrn: goal met for this agenda item? 18:21:15 (for single dropdown vs. multi) 18:21:27 amcrn, single dropdown +1 18:21:27 I’m not very familiar with the look and feel of the horizon project atm. are there existing screens that show multiple drop downs? 18:21:27 i think we're all ok with single 18:21:51 agreed 18:21:55 I can withdraw my ? if we are ready to vote 18:22:26 any voters for double? 18:22:31 if not, we can move on 18:22:34 -1 double 18:22:36 esp: I believe you can talk to them for guidance, but ultimately it's for the team to decide. 18:22:48 single +1 18:22:51 SlickNik: k, I’m gonna sit out of this vote :) 18:22:56 single +1 18:23:00 single +1 18:23:02 single +1 18:23:09 that's fine with me. single that is. 18:23:12 one question though: 18:23:12 at the end of the day, u wont have 80 different active mysql-5.X 18:23:12 (amrith, married) 18:23:15 so single ++ 18:23:23 amrith: lol u cant vote for two 18:23:24 abstain 18:23:29 single +1 18:23:30 single +1 18:23:39 single +1 18:23:41 single +1 18:23:45 single 18:24:13 this is like Kim Jung-Un's re-election results: 100% yes 18:24:21 alright, let's move on 18:24:26 lol 18:24:30 amcrn: hahahaha 18:24:32 amcrn: thanks. 18:24:33 amcrn, like Putin elections 18:24:36 amcrn i could vote against it if it makes you feel better 18:24:37 amcrn: Hey let's not get into divisive political topics here. 18:24:42 dougshelley66: lol 18:25:00 amcrn: I heard the other day on North Korea media they were contributing 99% of the code for the latest OpenStack releases. 18:25:05 #topic Perform integration testing for the heat based instances 18:25:28 yes this is basically to test heat based instance workflow 18:25:37 there is a patch for this https://review.openstack.org/#/c/66499/ 18:25:38 grapex: i didn't realize all you guys liven in North Korea 18:25:41 grapex: haha 18:26:04 grapex: that explains a lot :) 18:26:15 so for this we needed to change config values of trove-taskmanager.conf 18:26:16 i've got question to core about heat based flow 18:26:22 and a reastart of service 18:26:36 so the issue I had with this patch is how we are expecting that the taskmanager be restarted 18:26:51 that makes this test worthless if we ever expect to run it against a remote system 18:27:01 vipul: +1 18:27:20 vipul, i think for heat based testing we would need third-party CI 18:27:24 i do think we need to figure out ways to excercise both code paths though 18:27:31 shivamshukla: Also, since these tests seem to create a new instance, I think they should go into a new file rather than being added to instances.py 18:27:33 so my question is how can we do that other then this way 18:27:33 <_shalini_kh> So the idea is if we dont restart the service then it wont read use-heat true. 18:28:01 _shalini_kh: right, but if the taskmanager was not on the same machine as the tests.. then you couldn't do that anyway 18:28:23 vipul: +1 18:28:32 +1 to 3d party CI for heat based provisioning 18:28:37 <_shalini_kh> How will we change configuration without restarting..? 18:28:50 Another question is do we want to make testing heat it's own unique tests, or change the test config so it makes the existing tests use heat? 18:29:30 grapex, i guess we still need to restart taskmanager 18:29:34 Because if we modify the existing tests to work with Heat if the config is different, then it's a matter of setting up Trove to use Heat, then telling the test configs you want to test it that way 18:29:50 denis_makogon: what 3rd party CI, do we have it getting used elsewhere... 18:29:55 Although maybe it's easier to make these new tests 18:30:07 grapex: That would be ideal -- how do we get both code paths tested in a single Gate 18:30:27 grapex: +1 18:30:38 vipul: So maybe this idea of restarting taskmanager should be allowed but tweakable via the test config- 18:30:52 vipul: can we have a new heat gate? 18:30:53 So this may be a bit confusing, but imagine the heat tests are introduced as new tests 18:31:03 with the same groups as the existing instance create tests 18:31:04 I think we have a good chunk of our test suite that we'd want to run using this new ("heat" enabled) config. 18:31:24 +1 together for heat gate 18:31:26 So the tests work the same, but at that point it runs both sets of tests. In the VM, it restarts task manager 18:31:28 yogesh: yea, you could.. it would increase the overall time.. 18:31:52 but if you want to test remote, you basically disable one of those sets as well as the taskmanager restart 18:31:59 grapex, only provisioning tests can work with heat based trove, nothing else 18:32:01 vipul: at the cost of some time, a better abstraction 18:32:08 grapex, no resizes, no security groups 18:32:12 yogesh: Yes, but there are some holes in heat (esp. regarding resize) that we would have to fix before all our tests would run in that gate as it. 18:32:38 SlickNik, there are plans in heat to cover all cases required by Trove 18:32:39 SlickNik: it can be incremental 18:32:55 SlickNik, i've got several BP already approved in heat space 18:33:08 SlickNik, security groups update, volume resize 18:33:19 denis_makogon: pointers to BPs please... 18:33:37 yogesh: But then you'd have to maintain more, different test code for the different workflow. 18:33:38 yogesh, they already asssigned to my college 18:33:42 SlickNik heat gate answers no heat tests vs some tests 18:33:47 grapex: I could live with that.. so there would be a test.conf flag that says.. run non-remote tests.. and this one that restarts would fall into that category 18:34:26 vipul: Yeah. If there's two sets of tests, and you want to just run one- I think we'd have to disable one of the sets of tests. 18:34:53 That gets tricky. But I'm sure there's a better way I could think of with a bit more time. That way in the public we're able to test both. 18:34:54 so to make this happen sooner.. (heat gate would be a bigger effort) .. we can do what's in the patch, provided they provide a way via cfg to turn off the test shivamshukla 18:35:09 Now- in the distant past, when Reddwarf was a fork, we had a test that would restart nova after changing the configs 18:35:12 *nobody liked it* 18:35:14 i really want to see that heat works.. and the sooner we can get it into the default gate the better 18:35:17 vipul, but we need to think about heat gate 18:35:23 so we'd need to be careful, since if we do that wrong it could cause problems 18:35:28 denis_makogon: wanna help set it up? 18:35:40 vipul: I agree- right now we have no idea how well heat is working. 18:35:41 we need more testing resources denis_makogon 18:35:55 grapex: it is working smooth 18:35:58 vipul, first we need to refactor code to extract heat provisioning into it's own manager for taskamanager 18:36:07 vipul, and than setup the another gate 18:36:18 vipul we can set it up if required 18:36:38 and commit testing resources from our side 18:36:51 SnowDust: i mean compute resources SnowDust 18:37:03 SnowDust: It's not just about testing resources. You'd need compute capacity as well. 18:37:03 ;) 18:37:05 although that's not a huge issue 18:37:34 hmm 18:37:40 Maybe we should wait for datastore capabilities to make it easier to change the configs related to Heat 18:37:54 Because if we have to have test code that's mucking with a config file we will all be less happy 18:38:05 vipul, for now i agree with test.conf, but in the nearest future, we should think about it's own gate 18:38:09 but if there's an API for capabilities we could call, and then restart it, it will be much easier. 18:38:39 grapex: yea we can revise the test when that's in 18:38:46 As much as I'd like to spend time on a separate heat gate, I can live with having some _heat_ testing using the flag approach grapex and vipul mentioned earlier. 18:38:54 but I am also open to discuss a conf setting to turn testing switch between heat non heat 18:38:56 vipul: True- maybe we should wait though 18:38:57 grapex, how does the capabilities can help testing heat code ? 18:39:09 but how come changing test.conf will create instance using heat as it will only read from taskmanager.conf 18:39:24 so let's jsut do this.. fix the test to honor a flag.. get this in, at least continues to prove that we don't break heat 18:39:35 long term, we'd probably want a separate gate running in parallel using the infra/ci test resources. 18:39:46 SlickNik, ++ 18:40:28 Awesome...agreed 18:40:30 vipul: +1 18:40:53 +1 18:41:07 ok so we will need a flag for non remote for which we need to disable our test 18:41:12 vipul: so by honor a flag, you just mean we could turn off the "restarr taskmanager" bit, right? 18:41:21 I think I agree with were we've ended up on this 18:41:23 grapex: yes.. or like shivamshukla says.. 18:41:25 +1 18:41:40 Cool, I think we've got a path forward on this. 18:41:43 Let's move on. 18:42:06 #topic Neutron Support, SecGroup Management, and Networking 18:42:23 annashen, suppose you here =) 18:42:31 let me talk first 18:42:56 denis_makogon: sure, you can go first. 18:43:02 at the previous BP meeting we talked about supporting neutron and nova-network 18:43:16 i proposed to make it switchable via config 18:43:17 I have some questions regarding this, but will wait until you finish. 18:43:32 BP didn't got approved, yet 18:43:57 so, implementation will cover Base interface and nova-network implementation 18:44:00 So is this just "Please look at BP and approve"? 18:44:06 no 18:44:13 not at all 18:44:30 i'd like to hear thoughts of community over this 18:44:53 denis_makogon, I'm unsure what you are asking 18:45:24 so the only thing that i was uncertain of in the BPs is that neutron support is mutex with nova-network and there's no way to enable neutron in an existing deploy 18:45:35 So, this topic has three blueprints, so I'm a bit confused as to the aspect we're discussing 18:45:37 i'm asking community to say if it has suggestions or concerns, if not, i guess BP can be approved 18:45:47 #link https://blueprints.launchpad.net/trove/+spec/network-manager-spec 18:46:03 So, frankly I'm confused as to why there are 3 separate BPs on this. 18:46:32 SlickNik, one for refactoring current code, and implementing nova-network driver 18:46:48 denis_makogon: I don't see it that way 18:46:50 other for neutron 18:46:53 That seems like it could all be one 18:46:58 one of these looks like creating a network manager for the existing trove functionality 18:47:19 grapex, that's mine 18:47:24 The one from Anna Shen, "Secgroup management via neutron vs nova-network", is about using neutron in addition to nova-network 18:47:29 so it looks like there's some overlap 18:47:31 Why would you need a separate BP to "refactor" code with the sole goal of achieving what another BP already aims to achieve? 18:47:55 then there's another one from Anna called "Neutron Support for Trove" that's about adding the two networks to each Trove instance which is related to what Juice discussed a few weeks back 18:47:57 SlickNik, we decided to split them 18:48:03 different tasks 18:48:29 we don't need two BP for tasks 18:48:30 You can have different tasks as part of the same BP. That's what "partially-implements" is for. 18:48:32 So I'm guessing "Neutron Support for Trove" should not be a part of today's discussion as it seems less like the two other ones 18:48:43 grapex, i think annashen 's BP about using neutron instead of nova-network 18:49:07 grapex: Yea i think that's a separate thing that could land after this refactoring/manager implemetatin 18:49:23 vipul, yes, that's what i'm saying 18:49:36 denis_makogon: i'm talking about the one Juice discussed 18:49:36 denis_makogon: Well these look very similar: https://blueprints.launchpad.net/trove/+spec/secgroup-mgmt-via-neutron and https://blueprints.launchpad.net/trove/+spec/network-manager-spec 18:49:38 denis_makogon: https://blueprints.launchpad.net/trove/+spec/secgroup-mgmt-via-neutron needs the refactoring to happen to implement it, yes? 18:49:57 ok, my concern is with the neutron BPs 18:50:18 #link https://blueprints.launchpad.net/trove/+spec/neutron-support 18:50:18 grapex, they cannot be similar 18:50:39 grapex, i'm not aiming to implement new API for SGs 18:51:03 annashen: https://blueprints.launchpad.net/trove/+spec/secgroup-mgmt-via-neutron and https://blueprints.launchpad.net/trove/+spec/neutron-support are the same 18:51:06 should be the same 18:51:10 so before we rush to integrate a bunch of neutron code, what's with the disclaimer that no-one with an existin trove deploy can use the features? 18:51:13 denis_makogon: Maybe I'm misreading this but the one from Ana says "use neutron to do the security group stuff" with comments by you saying "let's make a manager base class to switch between neutron and nova-volume" 18:51:24 grapex, my goal is to refactor actual code to have an ability to switch from nova-network to neutron harmlessly 18:51:32 denis_makogon: Then yours is about making a network manager to switch between neutron and nova-network 18:51:52 kevinconway: I don't know if there is a good way for both to co-exist in hte underlying infrastructure anyway 18:51:55 for the record I prefer denis's blueprint here- I think we should make an interface so we can use nova-network or neutron 18:52:05 i don't think you can have a Nova deployment with both kevinconway 18:52:10 this may be a mild tangent - but could someone state what the current support (or lack therof) for neutron is in trove today? 18:52:28 dougshelley66: we're not using neutron today. 18:52:29 vipul: not necessarily both, but there is _no_ migration path for an existing deploy 18:52:41 vipul, i was thinking there might be more complicated scenarios for sec group so i created another one 18:52:43 kevinconway: that's a infrastructure migration issue really.. 18:52:43 dougshelley66, what denis_makogon told me yesterday is that there is NO support today 18:52:59 Now it also seems like denis_makogon's blueprint came after annashen's 18:53:16 so shouldn't we understand what the issue(s) are and have one BP to address them? 18:53:20 vipul: is there a precedence in OS showing migrations from network to neutron? 18:53:52 kevinconway: i don't think there is a good way to do it :) -- what i've seen really is set up a new cloud with neutron, migrate workloads 18:53:56 kevinconway: I think we can worry about migrations as a later step, especially if we allow either nova-network or neutron to work going forward 18:54:01 grapex, mine BP comes first because without any refactoring it would be hard to use neutron based network attributes management over existing code 18:54:03 which is why not many have movd onto neutron 18:54:27 no, i agree we should have support for neutron. i think it's a bad idea to have _zero_ plan to upgrade exiting troves to use it 18:54:51 what other feature have we implemented where the upgrade strategy was "start over"? 18:55:02 SlickNik and core: I guess the question is which of these two blueprints do we want to keep? 18:55:13 kevinconway: i don't see how that is a Trove responsibility... esmute is implementing cross-region restore.. and that could be used by Trove users to switch to a new infrastructure 18:55:22 grapex, good question, i suppose 18:55:35 denis_makogon, annashen it sounds like there are some questions being asked here. (a) there are two tasks and three blueprints. is there a reason for this? (b) is there a requirement to switch back and forth from neutron to nova? would someone use that? and (c) what are the issues involved in switching to neutron from nova. 18:55:36 kevinconway: I think there *will* be an upgrade strategy later. Though vipul is right, that may be the responsibility for Neutron and not necessarily us 18:55:54 let me rephrase my conerns: I think upgrade/migration documentation for this feature should be a pre-req to completion 18:56:31 SlickNik and core: I'd equally direct my questions above to y'all (or is that all'o'y'all) 18:56:52 amrith, we would npt switch to neutron once nova-network will be deprecated 18:56:57 amrith, trove currently support nova-network, by introducing neutron, we do not want nova-network going away immedidately 18:57:09 amrith: There isn't a requirement to switch back and forth. 18:57:39 SlickNik, I misread denis_makogon' earlier comment. 18:57:41 amrith: At some point, neutron becomes the preferred way of doing networking in your OpenStack cloud. 18:57:42 SlickNik: It's time for you to exercise your PTL POWARS. One blueprint must live... and one shall die! 18:57:43 I agree 18:57:48 we need a way to pick which backend Nova or Nuetron.. that's it. We also need to implement the Neutron backend 18:57:56 That's my take anyway 18:58:05 amrith, nova-network should be deprecated at the end of the Juno, i suppose, so as nova-network driver also would be marked as deprecated 18:58:06 denis_makogon: annashen: a side question, do we plan to cover its flow through heat, in the alternate heat-enabled path... 18:58:07 and let's get rid of these BPs! 18:58:07 amrith: And we need to be able to run trove on an OpenStack Cloud that is running neutron, instead of nova-networking. 18:58:21 yogesh, someday - yes 18:58:35 amrith: Those are all the requirements I see for this for now. 18:58:37 so the questions that remain are these, why 3 bp's, and what are the issues in moving to neutron; would that migration be someone elses responsibility 18:58:45 right, please vote, go or no go 18:58:58 SlickNik, looks like we are saying same thing; thx 18:59:17 wouldn't it make sense for someone to draft a BP that outlines the requirements first? 18:59:25 as for me i see two tasks at now 18:59:29 So here's my view on the current BP issue. 18:59:31 dougshelley66: yet another BP! 18:59:47 Let's have 1 BP for supporting neutron. 18:59:49 clearly none of the existing BPs has enumerated the requiremetns 18:59:57 which is why we are having this discussion 19:00:00 SlickNik, agreed 19:00:01 diugshelley66: +1, i think THE bp should be elaborated 19:00:09 I'm exhausted 19:00:21 And in it detail all the gaps that we currently have that need to be filled. 19:00:31 SlickNik +1 19:00:39 slicknick +1 19:00:41 Multiple folks can work against that 1 BP, if needed. 19:00:43