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