| opendevreview | Merged openstack/octavia master: Added olso_middleware.sizelimit support https://review.opendev.org/c/openstack/octavia/+/902049 | 09:10 |
|---|---|---|
| gthiemonge | #startmeeting Octavia | 16:00 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'octavia' | 16:00 |
| gthiemonge | o/ | 16:00 |
| johnsom | o/ | 16:00 |
| tweining | o/ | 16:00 |
| gthiemonge | #topic Announcements | 16:01 |
| gthiemonge | well I have no announcement... | 16:01 |
| gthiemonge | did I miss something? | 16:02 |
| johnsom | Gerrit is having many problems right now. | 16:02 |
| johnsom | They seem related and in theory have been fixed in upstream gerrit, but not yet deployed for openinfra | 16:02 |
| gthiemonge | hm | 16:02 |
| johnsom | One issue is rebases will show as the original author instead of the person triggering the rebase in IRCbot. | 16:02 |
| gthiemonge | ack | 16:03 |
| johnsom | The more troublesome is patches can pass the gate pipeline, but not be marked as merged in gerrit | 16:03 |
| gthiemonge | wow | 16:03 |
| gthiemonge | good, our only approved patch looks correct | 16:03 |
| johnsom | Yeah, so just a heads up. It's not clear if a recheck will resolve or if there is a bigger issue. | 16:04 |
| gthiemonge | ok, thanks for the update johnsom | 16:05 |
| gthiemonge | #topic CI Status | 16:07 |
| gthiemonge | we still have some patches in review for the DB deadlock issue that we've seen multiple times in the CI | 16:07 |
| gthiemonge | https://review.opendev.org/c/openstack/octavia/+/899662 | 16:07 |
| gthiemonge | https://review.opendev.org/c/openstack/octavia/+/899663 | 16:07 |
| gthiemonge | the greenlet error still appears randomly, no update for this issue :/ | 16:08 |
| gthiemonge | #topic Brief progress reports / bugs needing review | 16:10 |
| 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 |
| gthiemonge | https://review.opendev.org/c/openstack/octavia/+/901435 | 16:10 |
| johnsom | I created a patch for handling certificates with no subject or CN: | 16:10 |
| johnsom | #link https://review.opendev.org/c/openstack/octavia/+/901689 | 16:11 |
| johnsom | I would like others to look at the comments there about the certificate definition. | 16:11 |
| johnsom | They are asking for a call out that the certificate should meet the x.509 standard. | 16:11 |
| johnsom | Which to me is the a bit silly given that is the standard that defines what a certificate *is* | 16:12 |
| tweining | ok, I will have a look | 16:12 |
| gthiemonge | ok, it's on my todo list | 16:12 |
| 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 |
| tweining | https://review.opendev.org/q/I700c65fb17bad28b2b922e03d9c94c4716de9cbe | 16:13 |
| tweining | I guess johnsom could approve it too | 16:14 |
| gthiemonge | johnsom is the owner | 16:14 |
| johnsom | Those are my patches | 16:14 |
| gthiemonge | I'll review the backports | 16:14 |
| johnsom | So, technically I should not approve them | 16:14 |
| 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 |
| gthiemonge | the policy says "Where a team member has backported a fix, a single other +2 is sufficient for approval." :D | 16:15 |
| gthiemonge | anyway I'll review them | 16:15 |
| tweining | thanks | 16:15 |
| gthiemonge | it's not a simple bugfix | 16:15 |
| johnsom | +1 | 16:16 |
| gthiemonge | #topic Open Discussion | 16:16 |
| gthiemonge | ok I have one topic | 16:16 |
| gthiemonge | a user opened a launchpad bug because of an issue when using ACTIVE-STANDBY + additional_vips + HMs | 16:17 |
| gthiemonge | https://bugs.launchpad.net/octavia/+bug/2044247 | 16:17 |
| gthiemonge | a summary: | 16:17 |
| gthiemonge | basically, let's consider a LB in ACTIVE_STANDBY with vip_subnet_id subnet1 and additional_vips (subnet2 and subnet3) | 16:17 |
| 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 |
| gthiemonge | it means that the BACKUP amphora doesn't have any IP addresses on subnet2 and subnet3 | 16:18 |
| 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 |
| gthiemonge | so the BACKUP amp reports that the member is DOWN | 16:19 |
| gthiemonge | there's a workaround/mitigation: | 16:19 |
| 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 |
| gthiemonge | so now my questions: | 16:20 |
| gthiemonge | is it a bug? should we fix the code (and how?)? should we only document this behavior? | 16:20 |
| gthiemonge | (I'm not expecting an answer now, you can take your time and reply in the launchpad) | 16:21 |
| gthiemonge | comment 3 shows the network configuration in the amphorae https://bugs.launchpad.net/octavia/+bug/2044247/comments/3 | 16:21 |
| johnsom | Yeah, that is an interesting scenario where they are not specifying subnets for members that are on "additional VIP" subnets. | 16:23 |
| gthiemonge | I don't want to always allocate fixed ips for additional VIPs, that would consume too many IPs for a LB | 16:23 |
| johnsom | Yeah, there are definitely concerns about consuming IPs, especially on the "public" or "external" networks | 16:24 |
| tweining | is it possible to know during request validation whether there are additional VIPs used or not? | 16:26 |
| gthiemonge | like checking that the member IP belongs to the CIDR of an additional VIP? I don't really like this idea | 16:27 |
| gthiemonge | the member could also be on another subnet (routable from a VIP subnet) | 16:27 |
| tweining | I mean to require the subnet id in such case as described there | 16:27 |
| tweining | but yeah, if we don't consider it a bug we should at least document it | 16:28 |
| johnsom | It is definitely worth a release note at least | 16:29 |
| 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:29 |
| gthiemonge | (in the amphora-driver) | 16:30 |
| gthiemonge | not in the API | 16:30 |
| johnsom | Hmm, why not in the API? It seems like we could check that | 16:30 |
| gthiemonge | because this issue is limited to the amphora-driver | 16:31 |
| gthiemonge | (we don't know how a 3rd party provider could handle it0 | 16:31 |
| gthiemonge | ) | 16:31 |
| johnsom | Hmm, ok, I get your point | 16:32 |
| 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 |
| gthiemonge | and a patch for the amphora-driver | 16:33 |
| tweining | sounds good. | 16:34 |
| gthiemonge | thank you guys! | 16:35 |
| gthiemonge | any other topics for today? | 16:37 |
| tweining | not from me | 16:37 |
| johnsom | I don't think I have anything else | 16:37 |
| gthiemonge | ok | 16:38 |
| gthiemonge | then, have a good week! thanks! | 16:39 |
| gthiemonge | #endmeeting | 16:39 |
| opendevmeet | Meeting ended Wed Nov 29 16:39:21 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:39 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-11-29-16.00.html | 16:39 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-11-29-16.00.txt | 16:39 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-11-29-16.00.log.html | 16:39 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be restarting momentarily for a patch update to address a recently observed regression preventing some changes from merging | 21:09 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!