16:00:38 <gthiemonge> #startmeeting Octavia
16:00:39 <opendevmeet> Meeting started Wed Aug 18 16:00:38 2021 UTC and is due to finish in 60 minutes.  The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:39 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:39 <opendevmeet> The meeting name has been set to 'octavia'
16:00:45 <gthiemonge> Hi
16:00:48 <johnsom> o/
16:02:09 <gthiemonge> #topic Announcements
16:02:15 <gthiemonge> octavia-lib final release this week
16:02:23 <gthiemonge> #link https://review.opendev.org/c/openstack/releases/+/804667
16:02:39 <gthiemonge> next milestone is Xena-3 (Feature Freeze, Final release for client libraries) in two weeks.
16:02:59 <gthiemonge> I don't know if we need a priority review etherpad for Xena
16:03:09 <gthiemonge> any opinions?
16:03:39 <johnsom> Is everything landed for Xena we want to get it? If not, we probably should have a review sheet.
16:04:04 <gthiemonge> ack
16:04:30 <gthiemonge> I'll update the etherpad (url in the topic of the channel) for Xena
16:05:06 <gthiemonge> Collecting Pain Points
16:05:22 <gthiemonge> There's a thread on the openstack-discuss ML: Please Help On Collecting Pain Points
16:05:32 <gthiemonge> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024154.html
16:05:55 <gthiemonge> One of the community goals for Yoga would be to eliminate those pain points.
16:06:20 <gthiemonge> Contributors, Users, feel free to add your pain points in the following etherpad:
16:06:27 <gthiemonge> #link https://etherpad.opendev.org/p/pain-point-elimination
16:07:58 <gthiemonge> I've almost forgotten the last announcement: PTG
16:08:09 <gthiemonge> I created an etherpad for the Octavia PTG
16:08:16 <gthiemonge> #link https://etherpad.opendev.org/p/yoga-ptg-octavia
16:08:43 <gthiemonge> I'll add more topics there
16:08:56 <gthiemonge> Please add anything you would like to discuss
16:10:01 <gthiemonge> Any other announcements?
16:10:55 <johnsom> PTL elections are open
16:11:24 <gthiemonge> you're right
16:11:29 <johnsom> #link http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024093.html
16:12:08 <gthiemonge> thanks for the heads-up johnsom
16:14:12 <gthiemonge> #topic Brief progress reports / bugs needing review
16:14:42 <gthiemonge> FYI I rebased Adam's work (multi-vip support) on top of my "generic network management" patch
16:14:52 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/660239
16:14:59 <johnsom> Not a lot to report from my side. Some reviews going on. Right now I'm working on the "generic network management" patch review.
16:15:16 <gthiemonge> It is _not_ a priority for reviews, I guess it will wait until the Yoga cycle
16:15:24 <gthiemonge> johnsom: +1
16:16:07 <gthiemonge> the generic network management patch is important, I'd like to merge it before Xena-3
16:16:17 <johnsom> Yes
16:16:36 <gthiemonge> The amphorav2->amphora change as well
16:16:41 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/740432
16:17:12 <johnsom> Yes, I keep thinking I had already reviewed that but I guess not.
16:19:26 <gthiemonge> #topic Open Discussion
16:19:40 <gthiemonge> I have one question here, for johnsom and rm_work
16:19:51 <gthiemonge> I was reviewing this change: https://review.opendev.org/c/openstack/octavia/+/804485/4/octavia/network/drivers/neutron/allowed_address_pairs.py
16:20:34 <gthiemonge> I noticed that the listener object has a peer_port field. it was used in the split_listener haproxy configuration files, but it's no longer used
16:21:06 <gthiemonge> should we now consider that HAPROXY_BASE_PEER_PORT is always the peer_port for haproxy?
16:21:33 <johnsom> Yeah, we consolidated down to one port as everything on the amp has a shared fate.
16:21:34 <gthiemonge> (it also means that listeners on the same LB share the same peer tables)
16:21:39 <gthiemonge> ok
16:22:46 <johnsom> The old split way had multiple processes running and required multiple unique ports. We simplified that with the single process work.
16:23:32 <gthiemonge> so does it mean that this code for instance (https://opendev.org/openstack/octavia/src/branch/master/octavia/db/repositories.py#L1114-L1125) can be removed?
16:24:03 <johnsom> Once we remove multi-process yes
16:24:05 <rm_work> Oh on the multiple vip patch, remember it is NOT READY. Just a rebase is one small piece of the work necessary
16:24:28 <johnsom> lol, conversation branch
16:24:40 <gthiemonge> :-)
16:24:44 <rm_work> Yeah I got the notification a little late lol
16:24:54 <gthiemonge> rm_work: yeah still WIP
16:25:08 <gthiemonge> but it passes zuul CI
16:26:41 <gthiemonge> johnsom: removing multi-process... when can we do it? do we still support amps with multi-process?
16:28:23 <johnsom> There is an argument someone (grin) made a long time ago that the peer traffic should cross the lb-mgmt-net. This way that one port would not be used. This however requires using the netns support in haproxy and would slightly increase the security exposure. Multiple IPs using IPv6 might be the better option really. Like using link-local for example. But again, that is some engineering work.
16:29:26 <johnsom> On the multi-process, it has been in deprecation with warning messages for a while. I would have to check the deprecation expiration release. I expect we can remove it now. For sure in Yoga. Probably best to do early in Yoga.
16:29:53 <gthiemonge> Ok Cool!
16:30:58 <johnsom> Yeah, I think that was in Train, so... Probably good to be removed
16:31:29 <gthiemonge> this could be a topic for the PTG: Removing old stuff
16:31:41 <johnsom> Yes, there is a bunch of stuff to purge
16:33:17 <gthiemonge> Ok thanks johnsom
16:33:23 <gthiemonge> Any other topics?
16:35:33 <gthiemonge> Ok!
16:35:38 <gthiemonge> thanks everyone!
16:35:42 <gthiemonge> #endmeeting