20:00:03 <johnsom> #startmeeting Octavia
20:00:04 <openstack> Meeting started Wed Apr  5 20:00:03 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:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:07 <openstack> The meeting name has been set to 'octavia'
20:00:11 <johnsom> Hi folks!
20:00:27 <sshank> Hello
20:00:29 <xgerman> o/
20:00:31 <johnsom> It seems pretty quiet in the channel today.
20:00:39 <johnsom> Not sure how many folks will join
20:01:08 <johnsom> I also have a pretty short agenda
20:01:18 <johnsom> #topic Announcements
20:01:55 <johnsom> All I really have is we have made great progress on the Octavia v2 API.  I think we mostly have health monitor, status, and stats left.
20:02:14 <johnsom> I will probably port my quota endpoint over today as well.
20:02:18 <nmagnezi> o/
20:02:34 <johnsom> Mitaka goes EOL in five days.  4/10
20:03:02 <johnsom> That is also the Pike-1 milestone week
20:03:11 <johnsom> Any other announcements?
20:03:27 <xgerman> TC elections?
20:03:56 <johnsom> Oh yeah, I saw some campaign e-mails go out.
20:04:55 <johnsom> Also "reverify" may not work in the gates soon
20:05:12 <johnsom> #topic Brief progress reports / bugs needing review
20:05:31 <johnsom> I have been really focused in helping the testing effort for the API.
20:06:15 <johnsom> I also did some work to fix some breakage in the stable branches.  I might have a bit more to do there, but it's in pretty good shape.  Both devstack and DIB caused issues this round
20:07:00 <johnsom> Any other progress updates?  patches to look at?
20:07:18 <nmagnezi> i'm working on the user_group patch
20:07:28 <nmagnezi> #link https://review.openstack.org/#/c/429398/
20:07:42 <johnsom> How is that going?  Between rm_work and diltram do you have a plan?
20:07:47 <nmagnezi> basically what I have left is to take care of a "new agent old controller" scenario
20:07:53 <nmagnezi> yup
20:07:57 <johnsom> Ok cool!
20:08:03 <nmagnezi> the logic here basically will be
20:08:13 <nmagnezi> on controller just add deprecation note
20:08:33 <nmagnezi> on agent: use the baked user group file and if user_group is provided by the controller, ignore it
20:09:00 <nmagnezi> and by "ignore" i mean that it will not write the "group = xxx" in the haproxy.cfg file
20:09:13 <nmagnezi> i managed to get it working with a nice regex
20:09:25 <johnsom> Yeah, that makes sense
20:09:27 <nmagnezi> now i seem to have some encoding issue because newlines don't work
20:09:30 <nmagnezi> but i'll fix it
20:09:35 <nmagnezi> that's the update :)
20:10:03 <johnsom> Nice
20:10:03 <nmagnezi> i hope to finish this tonight (which is now, for me) or tomorrow
20:10:13 <nmagnezi> next week I'll be mostly off for holiday
20:10:21 <johnsom> Nice, enjoy!
20:10:26 <nmagnezi> thanks you :)
20:10:29 <nmagnezi> thank*
20:10:36 <johnsom> #topic Discuss asynchronous API and response handling
20:11:02 <johnsom> I was going to discuss how the async API is working with Octavia v2, but I'm not sure we have a good quorum this week.
20:11:23 <johnsom> It's spring break in some parts of the states, so a bunch of folks are traveling
20:11:36 <xgerman> seems like it
20:12:47 <johnsom> The summary here is the Octavia v2 API is an asynchronous API.  When folks make a update request, currently it returns the old data and a PENDING_UPDATE status.  This allows the backend to make the changes and rollback if the operation fails.
20:13:29 <johnsom> It can be a bit odd to get back the old information from an update call however, even though it's PENDING_UPDATE
20:13:53 <xgerman> yeah, since POST behaves differently
20:14:28 <johnsom> So the question is should we "fake up" the returned response from a PUT (update) call for the user.  Which means a followup GET would return different results.  Or should we leave it as is.
20:14:46 <johnsom> Yeah, with POST there is no old data, it's all new...
20:15:42 <xgerman> is there any guidance how other OpenStack stuff works
20:15:46 <xgerman> ?
20:15:58 <johnsom> The third option would be to capture the old settings, send those along with the new ones to the handlers, and update the database right away.  If something fails rollback using the saved data.  This seems a bit heavy weight
20:17:17 <johnsom> I have not seen guidelines, but I haven't dug to deeply.  I think we need to investigate this more.
20:17:40 <johnsom> We should probably do research and plan to come back next week to make a decision
20:17:54 <xgerman> my brief Google search (http://restful-api-design.readthedocs.io/en/latest/methods.html) suggests we are doing it all wrong and shiuld have used PATCH
20:18:22 <johnsom> Ha
20:18:50 <johnsom> That may very well be true, but that would mean shifting all of OpenStack....
20:19:26 <johnsom> There does seem to be some discussion of that here: https://specs.openstack.org/openstack/api-wg/guidelines/http.html
20:20:18 <xgerman> well, they agree with PATCH :-)
20:20:41 <johnsom> Maybe we look at PATCH in the future....
20:20:50 <xgerman> just saying…
20:21:21 <johnsom> We do need to maintain compatibility with neutron....
20:21:26 <xgerman> yep
20:21:44 <johnsom> Ok, let's do some research and come back with ideas
20:21:49 <xgerman> +1
20:21:55 <johnsom> #topic Open Discussion
20:22:01 <johnsom> Any other topics for today?
20:22:24 <nmagnezi> nothing on my end
20:22:35 <xgerman> not really —
20:22:38 <nmagnezi> oh, actually a question
20:22:48 <nmagnezi> was there any progress with active active?
20:22:56 <nmagnezi> i haven't seen anything for a while
20:23:05 <johnsom> Cool.  There is a good chance will with have the base API in place by Pike-1.  There is still stuff to add, but most of the base stuff will be there.
20:23:12 <nmagnezi> but i usually don't track patches who failed CI
20:23:35 <xgerman> yeah, we are thinking about that, too
20:23:39 <johnsom> nmagnezi No, it seems that the developers on active/active have not done work on it in a while.  We have not heard from them
20:24:02 <johnsom> We may have lost that development resource
20:24:09 <xgerman> and we are mulling if we should take over/salvage the code or start from scracth or…
20:24:25 <nmagnezi> that would be unfortunate
20:24:26 <johnsom> I don't want to drop it, but I'm not sure the rest of us have developers that can work on it now
20:24:58 <johnsom> There is a spec however, for another implementation of active/active
20:25:03 <johnsom> That is up for review.
20:25:07 <xgerman> yep
20:25:26 <johnsom> #link https://review.openstack.org/453005
20:25:35 <xgerman> I think if we just put in the base and then do something “simple” with ovs…not sure
20:25:59 <nmagnezi> oh that was the webex call
20:26:04 <xgerman> yep
20:26:09 <johnsom> Yeah, I feel the same.  The basics are there, we just need to do a bunch of work to fix the code
20:26:14 <johnsom> Yes
20:26:27 <xgerman> then we have the flavor spec which isn’t moving neither
20:26:33 <johnsom> Right
20:26:54 <johnsom> Maybe now that the API is in place that will gain steam again
20:27:09 <nmagnezi> hopefully
20:27:20 <xgerman> yeah, maybe I adopt active-active
20:27:35 <johnsom> That could be a plan
20:28:09 <johnsom> From the initial reviews I did, it's mostly duplicate code issues and missing act/stndby for the distributor
20:28:37 <johnsom> #link https://etherpad.openstack.org/p/Active-_Active_Topology_commits
20:28:41 <johnsom> That was the list
20:29:00 * nmagnezi wishes xgerman that the force will be with him
20:29:03 <xgerman> nmagnezi what are you working on those days?
20:29:55 <nmagnezi> xgerman, a bit external to the octavia code base, but I'm working with a TripleO core to support octavia deployment via tripleO. and we are getting very close
20:30:09 <xgerman> nice!
20:30:24 <xgerman> tripleO - smebody bought me a beer because he felt bad about it
20:30:26 <johnsom> It counts in my book
20:30:39 <nmagnezi> after that I plan to try to tackle upgrades/migrations (to allow everyone who use haproxy in namespace to eventually somehow migrate)
20:30:51 <xgerman> NICE!
20:30:55 <johnsom> Cool
20:31:07 <johnsom> Let me know if I can support you in that
20:31:11 <nmagnezi> also i would like to look into an option for kubernetes driver for Octavia
20:31:40 <nmagnezi> since nova lxd is a bit ubuntu centric..
20:31:46 <johnsom> Grin
20:31:52 <nmagnezi> :D
20:32:12 <johnsom> Well, we will support you in that adventure as well
20:32:28 <nmagnezi> hah
20:32:31 <nmagnezi> thank you :-)
20:32:31 <xgerman> yeah, I know K8 like tha back of my hand… so, yes
20:32:57 <johnsom> nova-lxd work is trying to get some bugs resolved last I heard
20:33:06 <nmagnezi> xgerman, on a related note, today i saw https://review.openstack.org/#/c/418530/
20:33:11 <nmagnezi> xgerman, is it ready for testing?
20:33:29 <xgerman> well, it relies heavily on filters
20:33:31 <nmagnezi> xgerman, (also, I'm not sure what is the expected end result, but i didn't actually read the patch just yet)
20:33:57 <nmagnezi> johnsom, yeah but diltram managed to get an amphora running, no?
20:34:09 <xgerman> oh, it replaces the lbaas plugin with a proxy one.
20:34:15 <johnsom> Also our first openstack client command is close to being done.  "openstack loadbalancer list"
20:34:28 <xgerman> I can do that on the proxy as well ;-)
20:34:40 <johnsom> Yeah, he got it working in a PoC with some patches.  Trying to upstream those now
20:35:02 <xgerman> nmagnezi if you switch off quotas in neutron you can create load balancer
20:35:07 <xgerman> with the proxy
20:35:27 <xgerman> so the proxy is ready but the API not so much…
20:35:37 <johnsom> What is the issue with quotas?
20:35:54 <xgerman> it will so a GET with a filter yo check and then bunk
20:36:10 <nmagnezi> xgerman, so when it is implemented, when I create a loadbalancer i will get created with an amp or haproxy ns? (sorry if it's a dump question)
20:36:15 <johnsom> Ah, yeah, ok.  So pending the filter support
20:36:36 <xgerman> nmagnexi it will proxy it to octavia so it will create an ovtavia LB for now
20:36:53 <xgerman> (until we have a namespace driver in Octavia)
20:37:23 <xgerman> since I replace the plugin all other drivers won’t work
20:37:25 <johnsom> It takes the request sent to neutron and directly proxies it to the new octavia API
20:37:30 <xgerman> yep
20:38:26 <nmagnezi> got it. :) and after Pike we won't need the neutron-lbaas code base anymore, right?
20:38:56 <johnsom> Well, we will keep it around for a while for deprecation purposes and to give time for folks to migrate
20:38:59 <nmagnezi> meaning, we eventually expect that we will be able to configure the plugin path directly to Octavia's codebase some time in the future
20:39:10 <xgerman> yes.
20:39:12 <nmagnezi> yup. migrations are important :D
20:39:26 <xgerman> and not sure if all vendors will port their driver…
20:40:24 <johnsom> I certainly hope so...
20:40:33 <johnsom> Ok, any other topics for today?
20:40:41 <nmagnezi> nop
20:41:25 <johnsom> Ok, Thanks for joining.  Have an nice break nmagnezi
20:41:34 <nmagnezi> thanks johnsom :)
20:41:40 <johnsom> #endmeeting