16:00:23 <gthiemonge> #startmeeting Octavia
16:00:23 <opendevmeet> Meeting started Wed Nov  2 16:00:23 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:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:23 <opendevmeet> The meeting name has been set to 'octavia'
16:00:31 <johnsom> o/.
16:00:33 <tweining> o/
16:00:35 <matfechner> o/
16:00:50 <strigazi> o/
16:01:04 <gthiemonge> Hi everyone
16:02:28 <gthiemonge> #topic Announcements
16:02:40 <gthiemonge> well, no announcement for this week
16:02:45 <gthiemonge> unless I missed something?
16:03:42 <johnsom> Two weeks from MS1, but otherwise I don't have anything this week
16:04:16 <gthiemonge> yes
16:05:10 <gthiemonge> #topic CI Status
16:05:23 <gthiemonge> a quick update on the FIPS job:
16:05:58 <gthiemonge> during the PTG we talked about it because it fails with timeouts
16:06:52 <gthiemonge> we mentioned that we could split the job into 2 jobs, or that we could reduce the number of tests (tls_barbican only)
16:07:08 <johnsom> yep
16:07:09 <gthiemonge> we already have a FIPS job with only tls_barbican (in the check pipeline, non-voting)
16:07:14 <gthiemonge> #link https://opendev.org/openstack/octavia/src/branch/master/zuul.d/projects.yaml#L69-L71
16:07:18 <gthiemonge> and the CI looks good
16:07:22 <gthiemonge> #link https://zuul.openstack.org/builds?job_name=octavia-v2-dsvm-tls-barbican-fips&skip=0
16:07:33 <gthiemonge> 1. do you think it is enough and that we should remove the octavia-v2-dsvm-scenario-fips job?
16:07:45 <gthiemonge> 2. should we split the octavia-v2-dsvm-scenario-fips job into 2 jobs?
16:08:12 <johnsom> I think the barbican tests are probably good enough for FIPS coverage
16:10:47 <gthiemonge> ok
16:11:04 <gthiemonge> I will propose a patch to remove the periodic job
16:12:50 <gthiemonge> #topic Brief progress reports / bugs needing review
16:13:23 <tweining> the vertical scaling optimization patches are now ready for review
16:13:28 <tweining> https://review.opendev.org/q/topic:amp-cpu-pinning
16:14:15 <gthiemonge> tweining: ok cool
16:14:23 <tweining> the nohz_full and SSL cache patches are non-essential
16:14:51 <gthiemonge> I have worked on supporting the zookeeper backend for jobboard in devstack
16:14:56 <johnsom> I am working on Barbican secrets consumers, i.e. registering that a cert/key is in use with Barbican. The proposed patches for Barbican have some bugs, but I am able to move forward with it. I hope to have a patch posted this week.
16:14:58 <tweining> well, not non-essential, but not that important
16:15:08 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/862671
16:15:20 <gthiemonge> it is almost ready, but grenade is failing because of a stupid issue, I have to fix it
16:15:36 <gthiemonge> the new octavia-v2-dsvm-scenario-amphora-v2-zookeeper job (non-voting) will replace octavia-v2-dsvm-scenario-amphora-v2 which is a duplicate of octavia-v2-dsvm-scenario
16:15:53 <johnsom> Nice
16:16:07 <johnsom> I think OSA wants to use zookeeper instead of Redis
16:18:05 <gthiemonge> it looks less hackish than the redis backend
16:18:23 <johnsom> But it brings Java
16:18:34 <gthiemonge> yeah
16:18:34 <johnsom> There are trade offs both ways IMO
16:20:32 <gthiemonge> #topic Open Discussion
16:23:40 <gthiemonge> Any other topics today?
16:24:02 <tweining> I have nothing today
16:24:37 <danfai> I would have some (support) questions regarding a specific setup, but we can have that after the meeting.
16:24:37 <gthiemonge> ok
16:25:04 <gthiemonge> danfai: yeah np, we can do that now
16:25:24 <danfai> I am trying to create an Octavia deployment on a flat network and like to only use one interface on the amphoras. Is there an easy way to do that by creating the nova instance and not care about vips?
16:26:15 <johnsom> Well, if you don't specify a subnet when adding members, it will use the VIP interface to access the backend member servers.
16:26:54 <danfai> So far I was able to patch out every netns call and spawn an haproxy on the same interface as the lb-mgmt port, but I had hoped there would be an easier way
16:27:02 <johnsom> But, the amphora driver always needs an lb-mgmt-net, so the amp will always have at least two interfaces. One outside the netns, one inside
16:28:25 <johnsom> Yeah, that just wasn't part of the design of the driver. The need for the lb-mgmt-net was based on the fact that Octavia can deploy in private tenant networks where there are no routes out.
16:28:36 <danfai> ok, then maybe another question. Would it be possible to specify the VIP at the time the listener is created?
16:29:56 <johnsom> Again, that was not part of the design of the amphora driver, so, no, not with the current code.
16:30:01 <johnsom> Curious though, why?
16:31:02 <danfai> Its a problem in the specific setup, because of dependencies we need the nova instance before the VIP...
16:32:04 <johnsom> Well, technically that is how it works. The nova instance boots with the lb-mgmt-net interface, then later in the LB create process we hot-plug the VIP interface in the netns.
16:32:35 <johnsom> But all of that happens inside the one API call for LB create.
16:34:34 <danfai> yes, for two IPs that works. I had hoped to have only one, but the order of the driver goes the other way around
16:35:26 <johnsom> Yeah, if you want to have an amp with only one port attached, you are looking at writing a new provider driver.
16:36:20 <danfai> ok thanks for the clarification, i had the same conclusion so far, that these are the options: 2 Ips or own provider driver
16:36:59 <johnsom> Yep. It's just a different use case than the amphora provider is targeting.
16:40:06 <strigazi> thanks for the input johnsom (I'm working with danfai)
16:40:30 <johnsom> Sure, NP
16:41:37 <gthiemonge> anything else? or we can close the meeting
16:42:37 <tweining> let's close it then
16:42:43 <gthiemonge> ok ;-)
16:42:47 <gthiemonge> thank you Folks!
16:42:54 <gthiemonge> #endmeeting