| opendevreview | Gregory Thiemonge proposed openstack/octavia master: Add option to limit recursion in to_data_model https://review.opendev.org/c/openstack/octavia/+/883063 | 08:15 |
|---|---|---|
| skraynev_ | @gthiemonge Hi. Sorry for the delay with the patch and thank you for the rebase. I was in long vacation :) if the approach for extra option make sense, I could add couple unittests and post it on review. wdyt? | 08:36 |
| racosta_ | Hi everyone, do you know if there is any architecture or functional limitation that prevents amphorae from attaching the port in different private subnets in the tenant's internal network? | 11:23 |
| racosta_ | I ask this because when I have multiple private-subnets, if one has exhausted the DHCP pool, the amphorae fails to attach, even with another available subnet. | 11:24 |
| racosta_ | If direct L2 connectivity (same private-subnet) is a 'hard' requirement. Any idea how to solve this problem? | 11:29 |
| gthiemonge | racosta_: hi, what version are you using? we have made some fixes in the handling of the subnets recently | 15:18 |
| racosta_ | Hi gthiemonge, I'm using OpenStack Yoga version. | 15:20 |
| gthiemonge | racosta_: are those subnets used for attaching the backend members? (not the vip) | 15:23 |
| racosta_ | To be honest, AFAIU, the HA proxy that runs inside the amphora uses multicast address by default. If there wasn't some modification in this engine to use unicast address, it seems to me that the two amphoras would need to be in the same L2 subnet. | 15:23 |
| gthiemonge | racosta_: we have this bugfix https://review.opendev.org/c/openstack/octavia/+/856992 in Yoga 10.1.0 (but it was not in 10.0.0) | 15:24 |
| racosta_ | The problem is that an amphora that failed (for some reason) and tried to failover! could not bind the port to the same subnet that it used before - because there are no more free subnet IP addresses... | 15:25 |
| racosta_ | humm, let me check this one | 15:26 |
| gthiemonge | is this subnet used for the VIP or for the members? | 15:28 |
| racosta_ | I'm talking about the VIP side - the subnet connected to the tenant's network. | 15:30 |
| gthiemonge | Ok, so for the VIP, when a user passes a vip_network_id parameter when creating a LB, a subnet is selected among all the subnets of this network, and the amphorae (VIP ports) will always use this specific subnet (even after a failover) | 15:32 |
| johnsom | Octavia Amphora do not use multicast. We do need L2 adjacency so the VIP address is reachable from both Amphora as needed in case of failures. | 15:33 |
| gthiemonge | IIRC if there's no IP address available in the subnet, a failover will fail | 15:33 |
| racosta_ | yeah... I have no way to control whether the tenant creates a small pool in his private subnet, but if he uses all the private IP addresses and the LB fails, a new amphora does not bind the port. | 15:33 |
| johnsom | Yeah, if you are out of IPs, we can't bind a port | 15:33 |
| racosta_ | any idea to solve this? | 15:35 |
| racosta_ | The new Amphora is created before removing the previous one, right? the IP address of the old Amphora gets 'stuck' and can't be reused then? | 15:38 |
| gthiemonge | the old amphora is removed after the new one is ready, so it means that we need more ip addresses to perform the failover | 15:39 |
| gthiemonge | I think that deleting an amphora before triggering the failover would be a workaround, it would deallocated the used IP addresses | 15:40 |
| gthiemonge | but if the failover fails, it will not rollback to the old amphora as a "normal" failover would do | 15:40 |
| racosta_ | ok, thanks for clarifying. | 15:44 |
| racosta_ | just a note: automatic failovers fail in this use case. | 15:50 |
| gthiemonge | #startmeeting Octavia | 16:00 |
| opendevmeet | Meeting started Wed Aug 30 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 |
| *** oschwart_ is now known as oschwart | 16:00 | |
| oschwart | o/ | 16:00 |
| tweining | o/ | 16:00 |
| johnsom | o/ | 16:00 |
| gthiemonge | #topic Announcements | 16:01 |
| gthiemonge | * 2023.2 Bobcat Release Schedule: R-5 | 16:01 |
| gthiemonge | we are close to feature freeze and final release for client libraries | 16:01 |
| gthiemonge | the release patch for python-octaviaclient was merged today | 16:02 |
| gthiemonge | we have already merged a lot of bugfixes for Bobcat | 16:02 |
| tweining | sounds good | 16:02 |
| gthiemonge | https://etherpad.opendev.org/p/octavia-priority-reviews | 16:03 |
| gthiemonge | I think I'll test again the new changes, check the CI, etc... | 16:03 |
| gthiemonge | to ensure we didn't break anything ;-) | 16:03 |
| gthiemonge | do you have any other announcements folks? | 16:06 |
| tweining | that tempest test for HSTS doesn't have a deadline, right? | 16:06 |
| gthiemonge | I think it's RC1 | 16:06 |
| johnsom | Yeah, we should get that in sooner than later | 16:07 |
| gthiemonge | but we could have it in another milestone release if it doesn't make it | 16:07 |
| tweining | okay, that might be a topic for later in the meeting then | 16:07 |
| gthiemonge | hmm last thing for Bobcat: | 16:08 |
| gthiemonge | the failover of IPv6 LBs is currently broken (neutron bug) | 16:08 |
| gthiemonge | https://bugs.launchpad.net/octavia/+bug/2028524 | 16:08 |
| gthiemonge | https://bugs.launchpad.net/neutron/+bug/2028651 | 16:08 |
| gthiemonge | there's a patch proposed to neutron, we need to track it | 16:09 |
| gthiemonge | https://review.opendev.org/c/openstack/neutron/+/892564 | 16:09 |
| gthiemonge | #topic CI Status | 16:10 |
| gthiemonge | centos jobs are ok now | 16:10 |
| gthiemonge | nothing else to report here | 16:11 |
| gthiemonge | #topic Brief progress reports / bugs needing review | 16:11 |
| johnsom | That was the global_venv thing right? | 16:11 |
| gthiemonge | johnsom: yes, one change in devstack that doesn't work well in c9s | 16:11 |
| oschwart | HSTS tempest tests are rebased on top of the TLS_TERMINATED listener API tests patch, it seems like some u/s jobs fail against that patch because they require the Barbican service as well | 16:12 |
| oschwart | https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/893066 | 16:12 |
| gthiemonge | johnsom: devstack is disabling it for c9s, but as we don't use directly their job definition, we had to apply the same fix | 16:12 |
| johnsom | Right, I was just trying to keep track of the issues with C9s | 16:12 |
| gthiemonge | oschwart: interesting I think the api job should use a noop driver instead of barbican | 16:13 |
| oschwart | yes they do, these are the u/s jobs that fail | 16:13 |
| johnsom | Yeah, there is a fake driver for the certificates stuff. | 16:13 |
| oschwart | so if we want to add API test that will test the TERMINATED_HTTPS protocol, I guess we will have to add barbican service (?) | 16:14 |
| gthiemonge | oschwart: I will take a look at those CI results | 16:14 |
| oschwart | johnsom: so I should have used that fake driver for the certificates instead? | 16:15 |
| oschwart | gthiemonge: thanks | 16:15 |
| johnsom | Yeah, the no-op jobs should probably use the no-op/local certificate driver instead of barbican | 16:15 |
| tweining | I will try to finish my hsts api tempest test on top before I leave for vacation | 16:15 |
| johnsom | #link https://github.com/openstack/octavia/blob/master/octavia/certificates/manager/local.py | 16:16 |
| johnsom | I'm not 100% what shape that is in. | 16:16 |
| johnsom | #link https://github.com/openstack/octavia/blob/master/setup.cfg#L92 | 16:17 |
| gthiemonge | maybe that doesn't work correctly because we haven't yet tested TLS_TERMINATED in the API jobs | 16:17 |
| johnsom | Yeah, I don't know what state Adam left that in | 16:17 |
| johnsom | #link https://github.com/openstack/octavia-tempest-plugin/blob/master/zuul.d/jobs.yaml#L489 | 16:18 |
| johnsom | In theory it's in use | 16:18 |
| gthiemonge | oschwart: we can check that together tomorrow | 16:19 |
| rm_work | I know I haven’t touched it in a LONG time, there may have been changes to how the manager interface works | 16:19 |
| rm_work | It was mainly intended only for local testing | 16:19 |
| rm_work | Ah that looks like what you want it for, so yeah it was working at least last time I checked 😅 | 16:20 |
| gthiemonge | rm_work: hi | 16:21 |
| gthiemonge | rm_work: thanks, we will verify it | 16:21 |
| oschwart | thanks rm_work gthiemonge johnsom | 16:22 |
| oschwart | gthiemonge: sure, let's take a look at it tomorrow | 16:23 |
| gthiemonge | #topic Open Discussion | 16:24 |
| oschwart | how should we continue with | 16:25 |
| oschwart | https://review.opendev.org/c/openstack/octavia/+/890814 | 16:25 |
| johnsom | Yeah, so I highlighted that this patch is an API behavior change. Where previously they would get a 404, now they will get a dict no mater what... | 16:27 |
| gthiemonge | as a user, I would find it weird that the API returns a 404 when requesting the stats of an existing amp | 16:28 |
| gthiemonge | but yeah this is what the API describes | 16:29 |
| johnsom | Well, it may not be an existing amp | 16:29 |
| gthiemonge | in case of non existing amp, line 220 would raise an exception, right? | 16:29 |
| gthiemonge | maybe we need to make it explicitly | 16:29 |
| johnsom | You could also consider the 404 to be "no stats exist" | 16:29 |
| gthiemonge | johnsom: yeah the api-ref describes it like that | 16:30 |
| gthiemonge | so if we want to fix this for the noop driver, we need to patch the noop drivers | 16:32 |
| gthiemonge | (like creating dummy entries in the stats table) | 16:33 |
| johnsom | The problem with this case is the drivers are never called, the request is handled purely at the API tier | 16:33 |
| johnsom | Yeah, I guess if the amp is created somewhere, it could insert a record in the sqlite | 16:33 |
| gthiemonge | yes | 16:35 |
| oschwart | sounds like another topic for tomorrow gthiemonge :) | 16:36 |
| gthiemonge | +1 | 16:36 |
| oschwart | thanks folks, nothing else from me | 16:37 |
| opendevreview | Tom Weininger proposed openstack/octavia-tempest-plugin master: Test new HSTS feature https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/881546 | 16:37 |
| gthiemonge | ok anything else folks? | 16:38 |
| johnsom | Not from me | 16:38 |
| tweining | no. the update I just pushed looks good, but I couldn't test it yet | 16:38 |
| gthiemonge | tweining: thanks | 16:38 |
| gthiemonge | tweining: enjoy your vacation | 16:39 |
| gthiemonge | thank you guys! | 16:39 |
| tweining | thanks | 16:39 |
| gthiemonge | #endmeeting | 16:39 |
| opendevmeet | Meeting ended Wed Aug 30 16:39:16 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-08-30-16.00.html | 16:39 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-08-30-16.00.txt | 16:39 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-08-30-16.00.log.html | 16:39 |
| opendevreview | Tom Weininger proposed openstack/octavia-tempest-plugin master: Test new HSTS feature https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/881546 | 17:03 |
| tweining | and now it should be complete as well | 17:03 |
| opendevreview | Vadym Markov proposed openstack/octavia-dashboard master: Add ability to create Prometheus listener https://review.opendev.org/c/openstack/octavia-dashboard/+/866064 | 17:26 |
| opendevreview | Merged openstack/octavia master: Fix error in agent-agent with empty UDP pools in IPv4+IPv6 LBs https://review.opendev.org/c/openstack/octavia/+/889696 | 17:29 |
| opendevreview | Merged openstack/octavia master: Fix UDP pool's member status in LB with additional VIPs https://review.opendev.org/c/openstack/octavia/+/889697 | 17:49 |
| opendevreview | Merged openstack/octavia master: Fix haproxy global maxconn with disabled listeners https://review.opendev.org/c/openstack/octavia/+/886446 | 18:05 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!