20:00:06 <johnsom> #startmeeting Octavia
20:00:11 <openstack> Meeting started Wed Mar  8 20:00:06 2017 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:15 <openstack> The meeting name has been set to 'octavia'
20:00:25 <johnsom> Hi folks
20:00:35 <diltram> o/
20:00:38 <nmagnezi> o/
20:00:55 <johnsom> #topic Announcements
20:00:57 <xgerman> o/
20:01:05 <johnsom> Octavia is now cycle-with-milestones release cycle
20:01:13 <xgerman> yeah
20:01:27 <johnsom> This means we will do Pike-1, 2, 3, and rc releases now.
20:02:03 <johnsom> Mostly this will help with end of cycle tasks like setting stable/pike for the agent,  etc.
20:02:51 <johnsom> The other announcement I have is tomorrow there is a meeting to talk about an alternative act/act method
20:03:07 <johnsom> 17:00 UTC Thursday March 9th
20:03:21 <johnsom> #link http://bit.ly/2lTz7wK
20:03:35 <johnsom> It's a webex style meeting
20:03:58 <nmagnezi> any related readings to do before that meeting?
20:04:17 <johnsom> No, I think it is a brainstorming kind of meeting where a spec will come out of it.
20:04:37 <johnsom> They are talking about using L3 anycast for act/act
20:04:53 <johnsom> That is about all I know.
20:05:06 <nmagnezi> may I ask, just to get a context of this, why are we discussing an alternative?
20:05:22 <nmagnezi> the current act/act work is going to get dropped?
20:05:24 <johnsom> It is just a proposal from the community
20:05:40 <johnsom> No, I expect it would be an alternate driver
20:05:53 <nmagnezi> ack. thanks.
20:06:24 <xgerman> yeah, we will keep teh current act/act work
20:06:25 <johnsom> All good questions we can ask...
20:06:37 <xgerman> :-)
20:06:57 <johnsom> I don't see any reason to drop the work that has been done for the current specs.
20:07:22 <xgerman> +1
20:07:30 <nmagnezi> aye. just asked to get the context of things. I'm not involved in this effort so just wanted to know :-)
20:07:32 <xgerman> quite the opposite
20:07:40 <johnsom> Anyway, please join if you can.  Should be an interesting conversation
20:08:42 <johnsom> Shortened urls are blocked on the wiki, so sharing it here...
20:08:55 <johnsom> Any other announcements?
20:09:18 <johnsom> Other than our gates are slightly broken at the moment....
20:10:19 <nmagnezi> which of the gates? anyone looking into this?
20:10:33 <johnsom> Yeah, rm_work and I are working on it now
20:10:45 <rm_work> T_T
20:10:56 <nmagnezi> let me know if I can help with something here
20:11:05 <johnsom> #topic Brief progress reports / bugs needing review
20:11:28 <johnsom> Lots of stuff needing reviews, so help out if you can.
20:12:09 <johnsom> I have been working on a bunch of clean up stuff and write ups about the PTG as well as reviewing the load balancer API
20:12:22 <johnsom> I hope to get back to the api-ref today
20:13:08 <johnsom> No other updates?
20:13:32 <johnsom> #topic Team mascot
20:13:36 <johnsom> #link https://etherpad.openstack.org/p/octavia-mascot
20:14:37 <johnsom> It doesn't look like we have new proposals, so we should move on to voting.
20:15:12 <johnsom> Please add your name to the roll call list next to your color and +1 next to the mascot you like
20:15:44 <johnsom> This way we won't have ballot stuffing....  grin
20:16:57 <johnsom> #topic Status of Active/Active development
20:17:31 <johnsom> Are any of the developers on those patches here?
20:17:58 <nmagnezi> i think perelman is not here atm
20:18:35 <xgerman> well, we have made some suggestions and haven’t seen them being picked up
20:18:46 <johnsom> I wanted to get an update on that work.  We have put up review comments, but I haven't seen any updates to those patches beyond rebases
20:18:54 <xgerman> +!
20:19:13 <xgerman> so we are wondering what is going on and how we can help
20:19:31 <johnsom> Yes and if they will have resources to work on this for Pike.
20:20:01 <johnsom> I was hoping we could iterate on those pretty quickly and get that merged early in Pike.
20:20:13 <xgerman> +2
20:20:51 <johnsom> Ok, so hopefully they will read the minutes and send an update.  I want to know if we need to find others to take over those patches.
20:21:13 <xgerman> nmagnezi any idea how we can get in touch with them or make them get in touch with us
20:21:30 <nmagnezi> i really don't know, sorry :<
20:21:43 <xgerman> k, thanks
20:21:45 <johnsom> I can try e-mailing directly I guess.
20:21:58 <johnsom> Similar topic:
20:22:07 <johnsom> #topic Status of flavors spec for Octavia
20:22:34 <johnsom> #link https://review.openstack.org/392485
20:22:52 <johnsom> This spec was posted, there was some discussion, but I haven't seen updates.
20:23:05 <johnsom> I don't see Evgeny here today either
20:23:40 <johnsom> Is there still interest in working on this in Pike?
20:24:05 <johnsom> No Kobis either...
20:24:39 <xgerman> ML?
20:25:00 <johnsom> Bummer.  This is one I wanted to make some traction on as the provider work will have flavors implications.
20:25:05 <johnsom> Yeah, probably ML time
20:25:23 <johnsom> #topic Discussion about how to migrate loadbalancers from legacy haproxy in namespace to run under Octavia
20:25:27 <xgerman> :-(
20:25:43 <nmagnezi> that one would be me :)
20:25:51 <johnsom> nmagnezi Wanted to talk about migrating LBs
20:25:56 <nmagnezi> yup
20:26:01 <nmagnezi> I spoke with rm_work and johnsom about this subject already, and I would like to raise it here for more opinions.
20:26:10 <nmagnezi> so
20:26:12 <nmagnezi> Many operating currently use lbaasv2 with the legacy haproxy in namespace.
20:26:14 <johnsom> It sounds like migrating between drivers, i.e. from netns driver to octavia driver.
20:26:29 <nmagnezi> I understand we currently don't have any tool to migrate existing loadbalancers from the old driver to Octavia, but from operators standpoint, I think this is an important option to have.
20:26:35 <xgerman> ok, so not netns -> new netns
20:26:43 <nmagnezi> So, we might want to capture such a thing in a spec (?) but I would like to know what people think about this and if they have any specific idea as for how such a thing should be implemented.
20:26:50 <nmagnezi> xgerman, yup
20:26:55 <johnsom> I do plan to have a method to migrate nlbaas netns lbs to octavia netns lbs
20:26:59 <nmagnezi> Please keep in mind that such a migration should be done in production env. Meaning: 1. It should have the option to roll back in case something goes wrong. 2. Minimal downtime, if possible.
20:27:36 <nmagnezi> johnsom, so maybe it makes more sense to have a two step migration
20:27:52 <nmagnezi> the one you mentioned should come as the first step
20:27:54 <johnsom> Yeah, across drivers there pretty much has to be some downtime as the data flows will change
20:28:16 <johnsom> nmagnezi Yes, likely.
20:28:42 <xgerman> yeah, vips change often as well
20:28:54 <johnsom> My first question would be to investigate if we can move the vip port to preserve the IP address
20:29:19 <xgerman> you can pass in the port after you cleared it I guess…
20:29:46 <nmagnezi> mmm, yeah that is indeed problematic. i guess if operators use floating ip that won't be an issue for them but we cannot assume everyone do that
20:29:52 <johnsom> We would probably need to create a flow that spins up the amp, plugs the backends  and configures, but be able to move the VIP port at the last minute.
20:30:04 <nmagnezi> yup
20:30:43 <xgerman> also how big a problem is it… do operators run 100 LBs they could recreate in a few hours or more like 1000s
20:30:46 <nmagnezi> can two drivers co-exists in one deployment at the same time? just for  the migration process?
20:30:56 <johnsom> Maybe a first step would be just removing the VIP port and passing it into octavia for an lb create.  Then optimize later
20:31:12 <xgerman> nmagnezi yes, they can
20:31:22 <johnsom> nmagnezi Yes, we will have multiple live drivers
20:31:36 <johnsom> You select with the "provider" parameter at LB create time
20:32:26 <xgerman> we just can’t move one LB from one provider to another
20:32:36 <nmagnezi> great. so as you said we can spin amps and configure them
20:32:42 <johnsom> Right, it would be a process
20:33:20 <nmagnezi> so i guess the main question here is what would be the best practice to migrate the vip
20:33:55 <nmagnezi> can we clear a vip without actually deleting the existing loadbalancer?
20:34:12 <johnsom> Right, start simple, look at how to detach from the old netns and pass in that port_ID to octavia on lb create...
20:34:40 <xgerman> but then you still need to somehow gather listeners/members/pools
20:34:42 <johnsom> I think so, but that would be the investigation.  Can you, how, what are the gotchas
20:35:19 <nmagnezi> xgerman, that we can read directly from the database i guess, no?
20:35:26 <johnsom> Right, it would need to mine the DB (bad idea) or do detail gets via the API
20:35:50 <xgerman> yep
20:35:59 <nmagnezi> johnma, why is it a bad idea to mine the db?
20:36:07 <nmagnezi> performance?
20:36:13 <johnsom> schemas change
20:36:27 <johnsom> It's not a "stable" interface like the API is.
20:36:32 <nmagnezi> it shouldn't change if i just read it, no?
20:36:53 <johnsom> Is this something you are thinking about adding to the Octavia API or be a standalone tool?
20:38:00 <nmagnezi> i was thinking on a standalone tool, but if we can get this to Octavia API it should even better (and that removes the db mining)
20:38:11 <johnsom> nmagnezi for example, the column "admin_state_up" in the DB could be renamed to "enabled".  where the API has to keep a stable name for it
20:38:13 <xgerman> I can see adding something which dumps all the LB and related info to later feed to a single create as a “backup” to the API
20:38:15 <nmagnezi> should be*
20:39:11 <johnsom> It will need octavia service account level permissions to be able to access the VIP ports, etc.
20:40:08 <nmagnezi> well we should only expect admins to do such actions, so is it a problem from that standpoint?
20:40:38 <xgerman> well, if operators like their users to self-migrate when it is conveneient for them…
20:40:39 <johnsom> No, just part of the thought process
20:41:07 <johnsom> I think it would be an interesting API really.
20:41:27 <johnsom> That way it could be something you allow your users to do.
20:42:25 <nmagnezi> that is an interesting option. also, it makes it far more complex to implement :D
20:42:47 <nmagnezi> but indeed it sounds like a better option
20:42:55 <johnsom> So, yeah, interesting idea.  Are you able to investigate and then propose a spec?
20:43:09 <nmagnezi> also xgerman made a good point about the "dump all LB"
20:43:46 <nmagnezi> johnsom, yes. it might take me couple of weeks to get to this, but it is something I can look into
20:44:14 <johnsom> Yeah, a backup/restore from the api perspective.  Interesting idea.  I would track that as a seperate spec
20:44:49 <xgerman> might be all you need if they can live with downtime
20:44:49 <nmagnezi> where do we expect to keep the backup?
20:44:59 <nmagnezi> sorry if it is a dump question.
20:45:04 <xgerman> the user would ask for it and move it to a place he likes
20:45:06 <nmagnezi> dumb*
20:45:12 <johnsom> Something that exports in "single call create" format
20:45:42 <nmagnezi> we have an single call create implemented already?
20:45:46 <johnsom> Yes
20:45:55 <nmagnezi> nice!
20:46:03 <nmagnezi> i was not aware of this. good to know.
20:46:11 <johnsom> One call that creates all of the parts of the LB (pools, members, etc.) in one API call
20:46:38 <nmagnezi> do we also have a single call delete (delete cascade was it called?)
20:46:57 <johnsom> We do not however allow multiple LBs in one call.  Maybe in the future
20:47:30 <johnsom> #link https://docs.openstack.org/developer/octavia/api/octaviaapi.html#create-fully-populated-load-balancer
20:47:48 <johnsom> The old docs.  I will be adding that to the new API-REF soon
20:47:59 <nmagnezi> ack.
20:48:33 <johnsom> Ok, any other questions about that?
20:48:38 <nmagnezi> okay I unless anyone has anything more to add. I have no additional questions. I will capture this in a spec.
20:48:52 <nmagnezi> no. thank you for your time :)
20:48:55 <xgerman> we should probably gather interest on the ML
20:48:59 <johnsom> #idea Allow Octavia driver migration of load balancers
20:49:04 <xgerman> not that we spend weeks and most people just run 10 LB
20:49:42 <johnsom> #idea Add a way to export your load balancer configurations in "single call create" format
20:49:46 <xgerman> it’s easy to gold plate such things
20:50:02 <johnsom> I never use those tags, so figured I would try them out....  grin
20:50:06 <xgerman> :-)
20:50:12 <nmagnezi> :)
20:50:22 <xgerman> I also think if you use ns you should be ok with downrime ;-)
20:50:35 <johnsom> True, those are "icing on the cake" features.  We have some baking left to do on the base....
20:50:47 <nmagnezi> xgerman, lol
20:51:08 <johnsom> A true statement....
20:51:17 <nmagnezi> i know :)
20:51:46 <johnsom> Ok, any other topics today?
20:52:12 <xgerman> oh, we have a spec for qos
20:52:34 <johnsom> Oh, I spoke with those folks at the PTG.
20:52:35 <xgerman> #link https://review.openstack.org/#/c/441912/
20:52:38 <johnsom> I need to read that.
20:52:45 <xgerman> I gave them some comments
20:52:51 <xgerman> but yes please read…
20:53:40 <johnsom> Yeah, it has been so busy since the PTG.  I am still catching up.  (the summary e-mails to the mailing list were a bit late, but they went out...)
20:54:24 <xgerman> I commented too much on CCF (see https://review.openstack.org/#/c/333993/11/specs/pike/common-classification-framework.rst) so they pulled me in
20:54:38 <nmagnezi> yup. highly detailed! I still need to read part 2 :)
20:55:12 <johnsom> Glad to know someone read it...  Grin
20:55:25 <xgerman> I not only read but forwarded it ;-)
20:55:39 <xgerman> spreading the gospel
20:55:45 <nmagnezi> hah
20:55:47 <nmagnezi> same here
20:55:47 <nmagnezi> :)
20:55:51 <johnsom> Nice.  Fire hose style....
20:56:13 <johnsom> Ok if there is nothing else I will end the meeting.
20:56:36 <johnsom> Thanks for the discussion today.  Good stuff.  Don't forget to join the webex tomorrow about act/act if you can.
20:56:54 <johnsom> #endmeeting