16:00:21 <gthiemonge> #startmeeting Octavia
16:00:21 <opendevmeet> Meeting started Wed Jan 25 16:00:21 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:21 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:21 <opendevmeet> The meeting name has been set to 'octavia'
16:00:26 <johnsom> o/
16:00:31 <gthiemonge> Hi everyone
16:00:34 <oschwart> o/
16:01:04 <tweining[m]> Hey
16:02:14 <yebinama> Hello
16:03:10 <gthiemonge> #topic Announcements
16:03:14 <gthiemonge> * Antelope Release schedule
16:03:18 <gthiemonge> just a reminder
16:03:27 <gthiemonge> we are 2 weeks from the final release for non-client librairies
16:03:36 <gthiemonge> AFAIK we have no open patch for octavia-lib
16:04:11 <johnsom> Yep, nothing there that is ready to go
16:04:56 <gthiemonge> and FYI we registered Octavia for the virtual PTG in March
16:05:14 <gthiemonge> any other announcements that I missed?
16:05:49 <johnsom> Individual registration is open for the March PTG as well, so sign up!
16:05:57 <johnsom> It is virtual and free
16:06:03 <gthiemonge> +1
16:08:01 <gthiemonge> #topic Amphorav2+Jobboard security issue
16:08:28 <gthiemonge> we had a new story last week about a security issue when using amphorav2+jobboard with taskflow logs set to >=INFO
16:08:55 <gthiemonge> when creating a TLS listener, the certificates and private_keys are written to the octavia worker logs
16:08:59 <gthiemonge> #link https://storyboard.openstack.org/#!/story/2010523
16:09:13 <gthiemonge> please note these important things:
16:09:24 <gthiemonge> - jobboard is not enabled by default in Octavia
16:09:48 <gthiemonge> - taskflow logger is only >=WARNING by default, INFO messages are not enabled
16:09:54 <gthiemonge> - the data is only visible by the admins of the cloud
16:10:35 <gthiemonge> the fix is already on master, patches have been proposed on stable branches
16:10:41 <gthiemonge> #link https://review.opendev.org/q/I2df8a49851feb1445b5128ce99b880ddb77782ad
16:10:49 <gthiemonge> (I had a merge conflict, so please review carefully)
16:11:13 <gthiemonge> then we will cut new releases when the patches are merged
16:12:00 <gthiemonge> any questions/comments?
16:13:44 <matfechner> o/
16:15:49 <johnsom> Thanks for working on this. I think the patch looks good.
16:16:13 <gthiemonge> thanks for the reviews ;-)
16:17:04 <gthiemonge> BTW I will open a bug against taskflow, the INFO-level messages are maybe printing too many details
16:18:34 <gthiemonge> #topic CI Status
16:18:35 <johnsom> Yep, let me know when that is ready for review
16:18:38 <gthiemonge> ack
16:19:16 <gthiemonge> for the CI: we had a new issue with grenade last week, because nova has enabled the sRBAC by default on master
16:19:37 <gthiemonge> johnsom fixed it by adding new roles for the users in octavia-tempest-plugin
16:19:46 <gthiemonge> johnsom: thanks!
16:19:50 <johnsom> NP
16:19:59 <gthiemonge> and for this week, nothing new to report
16:20:24 <johnsom> Yeah, I guess every cloud will need to make changes to every account on upgrade to Antelope due to the "secure-RBAC" goal.
16:21:50 <johnsom> This surprised me
16:22:41 <gthiemonge> yeah
16:24:32 <gthiemonge> #topic Brief progress reports / bugs needing review
16:25:20 <gthiemonge> so this week, I had to work on this security issue
16:26:29 <gthiemonge> and with tweining[m], we have worked on migration to openstacksdk in the neutron driver
16:26:37 <gthiemonge> I think it is ready for reviews now:
16:26:47 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/866327
16:27:27 <gthiemonge> and if you want to test it and you also have the ovn-octavia-provider in your env, you need to update it too (with https://review.opendev.org/c/openstack/ovn-octavia-provider/+/870514)
16:28:46 <gthiemonge> I think that for the rest of the week I will review the barbican secrets consumers patch
16:30:25 <gthiemonge> #topic Open Discussion
16:30:34 <oschwart> gthiemonge: ack
16:31:27 <yebinama> I have a question regarding pool lb_algorithm.
16:31:56 <gthiemonge> yebinama: hi
16:32:03 <yebinama> hello :)
16:32:21 <yebinama> I'm currently developing a provider driver for my company internal loadbalancing solution (that may become opensource in the future). We use 'MAGLEV' as the loadbalancing algorithm.
16:32:41 <yebinama> When creating a pool, the Octavia API checks the payload sent by the user and only allow to specify one of ROUND_ROBIN, LEAST_CONNECTIONS, SOURCE_IP or SOURCE_IP_PORT as lb_algorithm so I can't send "MAGLEV". Before doing a merge request, I wanted to know what would be the preferred way: either add 'MAGLEV' to Octavia library or maybe just remove the check from the Octavia API as each driver does its own check to
16:32:41 <yebinama> validate user payload and may support other algorithms than those 4.
16:33:25 <yebinama> BTW creating a driver is very easy and well documented
16:34:05 <johnsom> yebinama Thank you for the kind words.
16:34:30 <johnsom> So, Maglev is a load balancer offering, but I don't think it is a proprietary load balancing algorithm.
16:34:51 <yebinama> It' an algorithm from Google
16:35:02 <yebinama> You can use it in IPVS for example
16:35:04 <johnsom> It uses ECMP, which most default implementation use round robin
16:36:28 <johnsom> Some will use source tuples with consistent hashing
16:37:20 <yebinama> ECMP is used to reach the servers that are acting as lb, to contact the members it is indeed done wit some kind of hashing
16:37:44 <gthiemon1e> (sorry, I was dropped)
16:37:45 <johnsom> So, instead of "maglev" it might be best to use some kind of generic (i.e. used by other LB implementations) term for the algorithm.
16:39:18 <yebinama> Sure, something like "hashing" will be fine
16:39:35 <johnsom> I haven't read up on Maglev in a while, but I think it has an option (beyond round-robin) for a consistent hash based on protocol, source IP, source port, destination address, destination port.
16:39:53 <yebinama> Yep that is how we used it
16:40:07 <yebinama> To reach the same member, whatever the lb you hit
16:40:08 <johnsom> So, yeah, maybe "5-tuple" or something similar that we can explain in the docs somewhere.
16:41:00 <johnsom> That way other provider drivers can also use that algorithm if they support it and not be labeled "maglev".
16:41:37 <yebinama> Yes, it's a good solution
16:42:11 <johnsom> Yeah, so first step on that is to propose a patch to octavia-lib, adding the new algorithm.
16:42:37 <johnsom> Also, be careful to understand the different between the load balancing algorithm and session persistence. They are two different things.
16:43:21 <johnsom> LB algorithm is about how the first member server is selected, session persistence is about how subsequent packets for the client are handled.
16:43:34 <yebinama> Yes I'm talking about the lb algorithm
16:44:18 <yebinama> I may need to also update the python-octaviaclient as it doesn't use the octavia lib to check on user input
16:44:21 <johnsom> Yeah, if I remember, maglev does not support session persistence concepts, but generally behaves that way.
16:45:08 <johnsom> Correct, after it is added to octavia-lib, the main octavia, client, and dashboard will need to be updated to support this new algorithm.
16:45:18 <johnsom> It's really pretty easy to add these.
16:46:32 <yebinama> Sure I'll update these also
16:46:41 <johnsom> Oh, and probably the OpenStack SDK
16:47:20 <yebinama> I'll take a look on it to be sure
16:47:37 <johnsom> Yeah, so welcome. If you have questions this is a good place to ask them or the discuss mailing list.
16:47:45 <johnsom> We are happy to help you
16:47:47 <yebinama> So to open the request I go with "5-tuple"?
16:47:55 <yebinama> Thanks :)
16:48:27 <johnsom> Yeah, that is my personal thought on the algorithm name. Maybe others here or reviewers will have other ideas.
16:48:38 <johnsom> Propose it, can't hurt
16:48:45 <gthiemonge> it's ok for me
16:48:48 <johnsom> Easy to change if you get better feedback
16:49:33 <yebinama> Fine then. Thank you, I'll try to open it next week.
16:50:48 <gthiemonge> great!
16:51:59 <gthiemonge> anything else folks?
16:52:37 <oschwart> Nothing from me, welcome yebinama
16:53:10 <yebinama> thanks oschwart
16:53:31 <tweining[m]> No
16:53:51 <gthiemonge> ok, thank you guys!
16:53:53 <gthiemonge> #endmeeting