16:00:18 <gthiemonge> #startmeeting Octavia
16:00:18 <opendevmeet> Meeting started Wed Feb  2 16:00:18 2022 UTC and is due to finish in 60 minutes.  The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:18 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:18 <opendevmeet> The meeting name has been set to 'octavia'
16:00:24 <gthiemonge> Hi everyone
16:00:38 <noonedeadpunk> o/
16:01:15 <johnsom> o/
16:02:13 <gthiemonge> #topic Announcements
16:02:28 <gthiemonge> I don't have any announcements today. johnsom maybe?
16:03:11 <johnsom> Just that pip 22 broke many of the test jobs.
16:03:34 <johnsom> The fix in devstack merged today and is working it's way through the stable branches
16:04:41 <gthiemonge> yes, the gates for our stable/train & stable/ussuri branches, and for octavia-tempest-plugin are broken
16:06:27 <gthiemonge> #topic Brief progress reports / bugs needing review
16:06:59 <gthiemonge> Hey Folks I have 2 commits that need review for centos 9 stream support
16:07:06 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/816370
16:07:18 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/826769
16:07:31 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/816369
16:07:34 <gthiemonge> ok 3 commits!
16:08:43 <gthiemonge> I also have an old fix that already received a CR+2 (thanks johnsom)
16:08:48 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/805955
16:09:49 <gthiemonge> It fixes some members in ERROR that can be seen as ONLINE during a configuration change
16:14:00 <tweining> I have two tiny, related changes about the draining operating state for members.
16:14:23 <tweining> #link https://review.opendev.org/c/openstack/octavia/+/826897
16:14:30 <tweining> #link https://review.opendev.org/c/openstack/octavia-dashboard/+/826905
16:15:18 <gthiemonge> tweining: thanks for your contribution ;-)
16:15:23 <tweining> octavia did not process HAProxy's weight value correctly and octavia-dashboard didn't display that state
16:15:38 <tweining> :)
16:16:51 <tweining> I remember now that during my initial testing I saw the same issue with UDP as well. That issue is still unsolved.
16:17:23 <gthiemonge> I think the weight parameter is untested with UDP
16:19:37 <gthiemonge> #topic Centos FIPS as voting jobs
16:20:19 <gthiemonge> Folks, there's one proposal to have a FIPS job for centos 8 stream
16:20:30 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/798151
16:21:19 <gthiemonge> (basically with FIPS, the default params for cryptography are hardened)
16:21:37 <gthiemonge> I would like to discuss 2 things:
16:21:56 <gthiemonge> - should a FIPS-enabled centos 8 stream job replace the centos 8 stream job we already have?
16:22:36 <gthiemonge> - should it be a voting job? (our c8s job is non-voting)
16:22:54 <johnsom> I think they could be combined without issue.
16:23:44 <gthiemonge> a "basic" c8s would be useless, right?
16:25:19 <johnsom> Yeah, duplicate at least. The FIPS changes just puts additional restrictions on the OS. So, it's a more restrictive environment
16:26:20 <gthiemonge> I don't want to have too many jobs, I would prefer to remove the "normal" c8s job if we have a FIPS job
16:26:32 <johnsom> +1
16:26:46 <gthiemonge> then I'm not sure about the voting status
16:27:36 <gthiemonge> maybe we could make it voting in a follow-up patch
16:27:53 <johnsom> Yeah, c8s is on the PTI for yoga, we should have a voting job for that. However I know centos has been troublesome.
16:28:28 <johnsom> If it has stabilized I think we should make it voting, but if the OS is still too slow or causing problems we should keep it non-voting.
16:28:43 <johnsom> I am good with a phased approach
16:29:20 <gthiemonge> yes, I agree, I will ask the author of the change to make it non-voting, then we can revisit our decision in a few weeks
16:31:40 <gthiemonge> any other opinion?
16:32:16 <tweining> sounds sensible to me
16:34:45 <gthiemonge> ok thank you
16:34:51 <gthiemonge> #topic Open Discussion
16:35:04 <gthiemonge> any other topics you want to chat about?
16:35:33 <tweining> https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/824999 maybe?
16:36:22 <gthiemonge> tweining: sure, go ahead
16:36:41 <tweining> in particular the comments about the configurable IP and the POOL_MEMBERS enum need some clarification I think.
16:37:25 <gthiemonge> line 239
16:38:07 <gthiemonge> johnsom: do you think 192.0.2.0/24 could be routable? (this is a subnet for doc)
16:39:02 <johnsom> Ah, so tempest gets run in real environments to test upgrades, etc. It is quite likely that some clouds may be using that address space for internal needs. We have had feedback to this in the past.
16:39:51 <johnsom> I know we have this in other places as well, but I was raising the comment that maybe we should make those configuration items so if there is a conflict that causes artificial failures, the user can override them.
16:40:24 <johnsom> It's a minor comment
16:40:47 <gthiemonge> could we create a subnet with this CIDR? the amphora would not route the packets outside of our testing env
16:42:14 <johnsom> Yeah, maybe. But just making a config setting might be simpler
16:42:33 <johnsom> The test requires those to not respond
16:43:06 <tweining> is there a config file that I could use for that already, or should I use an environment variable for that instead?
16:43:21 <johnsom> Yes, the config setup already exists
16:43:28 <gthiemonge> tweining: https://opendev.org/openstack/octavia-tempest-plugin/src/branch/master/octavia_tempest_plugin/config.py
16:43:36 <johnsom> Yep, that
16:43:46 <tweining> thanks
16:43:53 <johnsom> They go in tempest.conf
16:44:14 <johnsom> But we can just set the default to be the 192.0.2.x addresses
16:45:11 <gthiemonge> sounds good
16:45:29 <tweining> ok, I would rather do that then.
16:46:48 <gthiemonge> I guess the 2nd question is: should we have a test that doesn't use a HM (for providers that don't support HM)?
16:46:51 <johnsom> +1 It's just a nice thing for our users to have an option
16:47:51 <tweining> the original intention behind this enum is to allow reusing the test for testing with the OVN provider.
16:48:01 <johnsom> Well, "in my opinion" a load balancer without health monitoring is useless, so....
16:48:37 <gthiemonge> does it support it now?
16:48:55 <johnsom> I don't know the status of the OVN driver
16:49:24 <gthiemonge> i don't know either
16:49:53 <johnsom> I was just calling out that having a test set with and a test set without is ...  a large matrix
16:50:27 <johnsom> If we think we need it, ok. I just wanted to ask the question.
16:50:31 <gthiemonge> https://opendev.org/openstack/octavia-tempest-plugin/src/branch/master/octavia_tempest_plugin/config.py#L256
16:50:46 <gthiemonge> ^ we could use this config flag
16:50:58 <johnsom> All of those should be removed IMO
16:51:11 <johnsom> I don't know if they even do anything anymore.
16:51:53 <johnsom> Could the test fall back to no HM if the create fails with a "unsupported feature" error?
16:52:19 <gthiemonge> yeah that could be a solution
16:52:38 <johnsom> All of those garbage "feature enabled" configs can be removed as the tests now "skip" when a driver doesn't support a feature.
16:53:02 <gthiemonge> yeah you're right
16:53:57 <johnsom> It's my bad that I got side tracked and didn't finish removing those. I think I was waiting on the IPv6 patch to land.
16:54:19 <tweining> ok, then I'll remove the enum again and use a bool for the fully_populated option like in my original implementation and add code for handling the unsupported feature case.
16:54:44 <gthiemonge> +1
16:55:05 <johnsom> +1 thanks
16:55:33 <tweining> thanks for the good discussion
16:55:33 <gthiemonge> tweining: ping me if you need more details
16:55:45 <johnsom> Same
16:55:54 <gthiemonge> anything else Folks?
16:57:04 <gthiemonge> ok
16:57:08 <gthiemonge> Thanks everyone!
16:57:11 <gthiemonge> #endmeeting