16:00:24 <gthiemonge> #startmeeting Octavia
16:00:24 <opendevmeet> Meeting started Wed May 31 16:00:24 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:24 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:24 <opendevmeet> The meeting name has been set to 'octavia'
16:00:32 <johnsom> o/
16:00:34 <matfechner> o/
16:00:37 <gthiemonge> hello
16:00:48 <oschwart> o/
16:01:43 <gthiemonge> #topic Announcements
16:01:50 <gthiemonge> no announcement this week
16:01:57 <gthiemonge> does someone have one?
16:02:14 <johnsom> I will be hosting a forum session for Octavia at the Vancouver Summit
16:02:28 <johnsom> It is on Wednesday morning at 9AM.
16:02:43 <johnsom> Is anyone planning to attend the summit?
16:02:43 <gthiemonge> \o/
16:03:39 <johnsom> Ok, it might be a quiet forum session. lol
16:04:12 <johnsom> If anyone is attending I will be there in person and happy to meet with people.
16:04:22 <gthiemonge> thanks johnsom!
16:05:58 <gthiemonge> #topic CI Status
16:06:02 <gthiemonge> good news
16:06:10 <gthiemonge> the CI is in a better shape this week
16:06:14 <gthiemonge> _this week_
16:06:22 <gthiemonge> We should not see any timeouts on 2023.1 and master
16:06:36 <gthiemonge> don't hesitate to ping me in case of issues
16:07:01 <gthiemonge> The FIPS issue in devstack was fixed but our jobs are still failing (timeout when connecting to the Cirros VM)
16:07:07 <gthiemonge> https://zuul.openstack.org/builds?job_name=octavia-v2-dsvm-tls-barbican-fips&skip=0
16:07:19 <gthiemonge> I will open a new launchpad issue for this new error
16:08:49 <johnsom> Thanks, maybe I can take a look and see if something jumps out at me. It's a busy day
16:09:05 <johnsom> ping me if you don't see a comment
16:09:22 <gthiemonge> it's not urgent (it's not blocking us)
16:10:18 <gthiemonge> #topic Brief progress reports / bugs needing review
16:10:37 <gthiemonge> just a kind reminder that we have a lot of open patches on stable branches:
16:10:42 <gthiemonge> #link https://review.opendev.org/q/project:openstack/octavia+status:open+branch:%255Estable/.*
16:10:52 <gthiemonge> (a reminder to me as well ;-)
16:16:13 <gthiemonge> #topic Open Discussion
16:16:14 <johnsom> I have done some reviews, also making some progress in understanding the SRIOV process
16:16:37 <gthiemonge> I have one topic:
16:16:52 <gthiemonge> I'm working on the implementation of the Active-Active L3 Distributor spec
16:16:57 <gthiemonge> #link https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/active-active-l3-distributor.html
16:17:21 <gthiemonge> so first, I'm not planning to use their DB schema, I will change some details
16:17:41 <johnsom> Boy I have not read that in a while. This was the Walmart plan right?
16:17:42 <gthiemonge> Question #1: do you think it requires an update of this spec?
16:17:57 <gthiemonge> hmmm, I don't remember, it's the BGP spec
16:18:04 <johnsom> Yeah, it was.
16:18:47 <gthiemonge> or should I create an new updated spec?
16:18:50 <johnsom> Umm, you could always copy it into a new version directory and make the required changes. Marking the old one and new as such
16:19:01 <gthiemonge> ack
16:19:08 <gthiemonge> I tihnk I will have more updates yeah
16:19:11 <johnsom> The old one had some patches, but didn't make it far.
16:19:32 <johnsom> I think a fresh review on a spec would be good too.
16:19:50 <gthiemonge> +1
16:20:22 <gthiemonge> this spec doesn't detail the new proposed API (only internals and DB changes)
16:20:38 <johnsom> I am excited that we have some good stuff moving forward, BGP, SRIOV, DPDK.
16:20:53 <johnsom> Yeah, that is not good
16:21:13 <gthiemonge> IMO we need to provide API calls for managing 2 new resources for BGP
16:21:22 <gthiemonge> - BGP peers (an external BGP daemon)
16:21:40 <gthiemonge> - BGP speakers (which is in the amphora in this implementation)
16:21:47 <gthiemonge> Question #2
16:22:21 <gthiemonge> do you think we can manipulate BGP objects with the Octavia API (a new endpoint like /lbaas/distributor/bgp/peer)
16:22:27 <gthiemonge> or do we need to have more "Generic" objects
16:22:31 <johnsom> Maybe a pass phrase field too?
16:22:44 <gthiemonge> ex: a new endpoint /lbaas/distributor which gets a {"type": "bgp-{peer,speaker}"} parameters
16:22:56 <gthiemonge> a passphrase field?
16:23:15 <johnsom> Don't you need to provide a pass phrase to some peers?
16:23:55 <gthiemonge> yeah there's an "auth_pass" parameter
16:25:30 <johnsom> Back to the API question #2, in REST you typically are talking about objects, so I would expect something more like /lbaas/distributor/<distributor ID>/bgp/peer/<peer ID> if you go down that path.
16:26:21 <gthiemonge> yeah, to me, it looks like a good way to do that
16:26:24 <johnsom> In those documents "distributor" is a concept and does not always have to be implemented as an actual process. One proposal had an implementation, the other did not need one.
16:27:37 <gthiemonge> in my mind the distributor will be an object that links the LB (and the amps), speakers in the amps and a remote peer
16:27:49 <johnsom> Cool, so yeah, a proposal for that approach would be cool
16:28:10 <johnsom> Yep
16:28:32 <gthiemonge> cool, I will propose a new spec!
16:28:41 <gthiemonge> BTW I'm not targeting Bobcat
16:28:55 <johnsom> Maybe just keep in mind, there might be some reason to have an LVS distributor or an OVN distributor.
16:29:55 <johnsom> That should help guide the API to be flexible for future implementations using "shiny new ball technology"
16:30:18 <gthiemonge> I thought the LVS distributor spec was an old spec that was propsoed before the BGP spec
16:30:25 <gthiemonge> ah ok
16:30:26 <gthiemonge> I see
16:31:00 <johnsom> It was, the LVS approach was intended to be a gate testable approach as BGP peers in the testing environment was not a thing
16:31:44 <johnsom> But yeah, the odds of someone implementing that are fairly low now.
16:32:09 <johnsom> I would just use it as an idea to guide the API design to be flexible
16:33:22 <gthiemonge> ack
16:33:36 <gthiemonge> johnsom: thanks for your feedback!
16:34:52 <johnsom> Sure, NP
16:35:19 <gthiemonge> any other topics folks?
16:35:57 <johnsom> I don't have anything else
16:36:16 <gthiemonge> ok!
16:36:30 <gthiemonge> thank you guys!
16:36:35 <gthiemonge> #endmeeting