16:00:17 <gthiemonge> #startmeeting Octavia
16:00:17 <opendevmeet> Meeting started Wed Nov 29 16:00:17 2023 UTC and is due to finish in 60 minutes.  The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:17 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:17 <opendevmeet> The meeting name has been set to 'octavia'
16:00:20 <gthiemonge> o/
16:00:25 <johnsom> o/
16:00:32 <tweining> o/
16:01:48 <gthiemonge> #topic Announcements
16:01:56 <gthiemonge> well I have no announcement...
16:02:01 <gthiemonge> did I miss something?
16:02:03 <johnsom> Gerrit is having many problems right now.
16:02:29 <johnsom> They seem related and in theory have been fixed in upstream gerrit, but not yet deployed for openinfra
16:02:45 <gthiemonge> hm
16:02:56 <johnsom> One issue is rebases will show as the original author instead of the person triggering the rebase in IRCbot.
16:03:11 <gthiemonge> ack
16:03:16 <johnsom> The more troublesome is patches can pass the gate pipeline, but not be marked as merged in gerrit
16:03:26 <gthiemonge> wow
16:03:53 <gthiemonge> good, our only approved patch looks correct
16:04:27 <johnsom> Yeah, so just a heads up. It's not clear if a recheck will resolve or if there is a bigger issue.
16:05:08 <gthiemonge> ok, thanks for the update johnsom
16:07:02 <gthiemonge> #topic CI Status
16:07:21 <gthiemonge> we still have some patches in review for the DB deadlock issue that we've seen multiple times in the CI
16:07:28 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/899662
16:07:33 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/899663
16:08:29 <gthiemonge> the greenlet error still appears randomly, no update for this issue :/
16:10:17 <gthiemonge> #topic Brief progress reports / bugs needing review
16:10:43 <gthiemonge> my fix for the TLS-HELLO HMs is approved but it's blocked because the parent patch is still waiting for another CR+2
16:10:49 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/901435
16:10:58 <johnsom> I created a patch for handling certificates with no subject or CN:
16:11:05 <johnsom> #link https://review.opendev.org/c/openstack/octavia/+/901689
16:11:25 <johnsom> I would like others to look at the comments there about the certificate definition.
16:11:52 <johnsom> They are asking for a call out that the certificate should meet the x.509 standard.
16:12:13 <johnsom> Which to me is the a bit silly given that is the standard that defines what a certificate *is*
16:12:21 <tweining> ok, I will have a look
16:12:43 <gthiemonge> ok, it's on my todo list
16:13:45 <tweining> since oschwart is not here today, I bring up these backports that are blocking another patch, which in turn blocks the tempest test patch about hsts
16:13:48 <tweining> https://review.opendev.org/q/I700c65fb17bad28b2b922e03d9c94c4716de9cbe
16:14:06 <tweining> I guess johnsom could approve it too
16:14:14 <gthiemonge> johnsom is the owner
16:14:17 <johnsom> Those are my patches
16:14:19 <gthiemonge> I'll review the backports
16:14:30 <johnsom> So, technically I should not approve them
16:15:05 <tweining> yeah, but didn't we say that backports that don't change the api can be approved by the owner after it has one CR+2?
16:15:17 <gthiemonge> the policy says "Where a team member has backported a fix, a single other +2 is sufficient for approval." :D
16:15:32 <gthiemonge> anyway I'll review them
16:15:40 <tweining> thanks
16:15:45 <gthiemonge> it's not a simple bugfix
16:16:28 <johnsom> +1
16:16:49 <gthiemonge> #topic Open Discussion
16:16:53 <gthiemonge> ok I have one topic
16:17:25 <gthiemonge> a user opened a launchpad bug because of an issue when using ACTIVE-STANDBY + additional_vips + HMs
16:17:30 <gthiemonge> https://bugs.launchpad.net/octavia/+bug/2044247
16:17:35 <gthiemonge> a summary:
16:17:54 <gthiemonge> basically, let's consider a LB in ACTIVE_STANDBY with vip_subnet_id subnet1 and additional_vips (subnet2 and subnet3)
16:18:29 <gthiemonge> when the LB is created the amphora has fixed ips only on subnet1 (it's required for VRRP connectivity) and the VIPs on subnet1, subnet2 and subnet3 are controlled by keepalived
16:18:56 <gthiemonge> it means that the BACKUP amphora doesn't have any IP addresses on subnet2 and subnet3
16:19:37 <gthiemonge> if a user creates a member that is on subnet2 (without specifying that the subnet_id is subnet2) the healthchecks from the BACKUP amp don't work (BACKUP amp have no address on subnet2)
16:19:44 <gthiemonge> so the BACKUP amp reports that the member is DOWN
16:19:56 <gthiemonge> there's a workaround/mitigation:
16:20:23 <gthiemonge> if the user specifies that the subnet_id of the member is subnet2, octavia explicitly plugs subnet2 into the amp, and fixed IPs are allocated in both amps
16:20:30 <gthiemonge> so now my questions:
16:20:45 <gthiemonge> is it a bug? should we fix the code (and how?)? should we only document this behavior?
16:21:12 <gthiemonge> (I'm not expecting an answer now, you can take your time and reply in the launchpad)
16:21:55 <gthiemonge> comment 3 shows the network configuration in the amphorae https://bugs.launchpad.net/octavia/+bug/2044247/comments/3
16:23:13 <johnsom> Yeah, that is an interesting scenario where they are not specifying subnets for members that are on "additional VIP" subnets.
16:23:47 <gthiemonge> I don't want to always allocate fixed ips for additional VIPs, that would consume too many IPs for a LB
16:24:38 <johnsom> Yeah, there are definitely concerns about consuming IPs, especially on the "public" or "external" networks
16:26:14 <tweining> is it possible to know during request validation whether there are additional VIPs used or not?
16:27:14 <gthiemonge> like checking that the member IP belongs to the CIDR of an additional VIP? I don't really like this idea
16:27:41 <gthiemonge> the member could also be on another subnet (routable from a VIP subnet)
16:27:59 <tweining> I mean to require the subnet id in such case as described there
16:28:54 <tweining> but yeah, if we don't consider it a bug we should at least document it
16:29:29 <johnsom> It is definitely worth a release note at least
16:29:57 <gthiemonge> ok, if the LB has additional vips and the user doesn't pass a subnet_id when creating a member, we could raise an exception
16:30:14 <gthiemonge> (in the amphora-driver)
16:30:18 <gthiemonge> not in the API
16:30:58 <johnsom> Hmm, why not in the API? It seems like we could check that
16:31:16 <gthiemonge> because this issue is limited to the amphora-driver
16:31:44 <gthiemonge> (we don't know how a 3rd party provider could handle it0
16:31:44 <gthiemonge> )
16:32:31 <johnsom> Hmm, ok, I get your point
16:33:22 <gthiemonge> ok so I will propose a release note + an update in the doc (I don't even think we have doc for additional_vips)
16:33:43 <gthiemonge> and a patch for the amphora-driver
16:34:43 <tweining> sounds good.
16:35:20 <gthiemonge> thank you guys!
16:37:21 <gthiemonge> any other topics for today?
16:37:41 <tweining> not from me
16:37:49 <johnsom> I don't think I have anything else
16:38:26 <gthiemonge> ok
16:39:15 <gthiemonge> then, have a good week! thanks!
16:39:21 <gthiemonge> #endmeeting