16:02:03 <johnsom> #startmeeting Octavia
16:02:04 <openstack> Meeting started Wed Jan 20 16:02:03 2021 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:07 <openstack> The meeting name has been set to 'octavia'
16:02:28 <haleyb> o/
16:02:32 <gthiemonge> hi
16:02:38 <johnsom> Hi there
16:02:48 <cgoncalves> hi
16:02:53 <johnsom> Hopefully rm_work will make it today
16:03:06 <johnsom> #topic Announcements
16:03:20 <johnsom> I don't have any announcements today really.
16:04:03 <johnsom> The foundation board elections have closed:
16:04:07 <johnsom> #link https://www.bigpulse.com/pollresults?code=1341255rQeCqjpQQ9VHPtCLbqxF
16:04:42 <johnsom> Also, devstack seems to still be having pip related issues. <sad face> So don't restack if you don't need to
16:04:50 <johnsom> Any other announcements today?
16:05:08 <haleyb> or make sure to install pip<20.3 which is what i did
16:05:23 <haleyb> pip install -U pip==20.2 or somesuch
16:05:30 <johnsom> Hmm, mine was force installing the new one....
16:05:51 <haleyb> i will not touch mine then, it stacked :)
16:06:00 <johnsom> I might have an upgrade flag in my localrc, I should check that
16:06:27 <haleyb> i use reclone=False or whatever that is
16:06:41 <johnsom> That would be magic. It was exploding on pip not being in the requirements repo venv bin.... Which is strange anyway.
16:07:40 <haleyb> devstack == magic don't ya know
16:07:41 <gthiemonge> I have reclone=True and it worked a few hours ago
16:08:00 <johnsom> Maybe magic happened overnight, I will give it a go again today
16:08:20 <johnsom> Any other announcements?
16:09:41 <johnsom> #topic Brief progress reports / bugs needing review
16:10:08 <johnsom> I don't have much on the Octavia side this week, some reviews. Most of my focus is on Designate/TripleO issues at this point
16:10:48 <gthiemonge> cgoncalves has a patch to add check and gate for victoria: https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/755210
16:11:37 <cgoncalves> thanks gthiemonge
16:12:20 <johnsom> Yeah, that would be good. lol
16:12:45 <johnsom> I wonder if there is an update about EOL for stein....
16:13:37 <haleyb> was i supposed to do that?
16:13:47 <johnsom> I think rm_work was on it
16:13:56 <haleyb> phew
16:14:30 <johnsom> Ok, if no one else has updates, I will move on
16:14:44 <johnsom> #topic Updating settings in a flavor profile after it is in use (ht-a10)
16:15:21 <johnsom> Hunter from A10 wanted to talk about mutable flavor profiles, Hunter, you have the floor....
16:16:04 <johnsom> I had hoped our PTL, rm_work, would make the meeting today because I think he has thoughts on this as well, but it seems he didn't make it.
16:16:20 <ht-a10> Right so title is self-explanatory. Our provider driver has a lot of dynamic options which are exposed through the flavorprofile. It's possible to update them at runtime on the device side, but the flavors impose a limitation on doing so.
16:18:14 <ht-a10> Currently, we have all the child object attributes in the flavor schema. SO when we want to update a member object attribute in the flavor schema the operator has to delete the entire SLB tree
16:19:08 <ht-a10> And then recreate which is time consuming. Would be nice to either have flavors for child objects as well or the ability to update the flavors. I understand not all options could be updated though. Potentially it could be at the discretion of the providers
16:19:24 <johnsom> #link https://github.com/a10networks/a10-octavia/blob/master/a10_octavia/api/drivers/flavor_schema.py
16:19:58 <ht-a10> And this is what ours looks like right now
16:20:00 <ht-a10> #link https://github.com/a10networks/a10-octavia/blob/master/a10_octavia/api/drivers/flavor_schema.py
16:20:20 <ht-a10> oh mb you beat me to it haha
16:20:58 <johnsom> Yeah, so currently, once an LB is using a flavor profile, it becomes immutable. It's basically expected that it is an LB creation time set of settings only and not something that will change once the LB is deployed.
16:21:26 <johnsom> It sounds like this isn't what is needed for your use case.
16:23:03 <johnsom> I see how adding a flavor/flavor profile to each object in the load balancer tree would limit the scope of "delete and recreate", but really that seems like a complicated and not-so-great user experience. I'm wondering if we can come up with a better idea.
16:23:50 <johnsom> ht-a10 And your use case needs the changes to be pushed out to running load balancers in addition to newly created ones right?
16:24:45 <ht-a10> Yeah we have configuration options which tie to the lb objects. Right now most of these reside in a config file which is updated and then from that we determine what else needs updating. Flavors is a step in the right direction, but it being immutable makes it expensive to tweak any of these options after deployment
16:26:35 <johnsom> I need to look through the settings  you have in the flavor profile schema. I wonder if some or all of those should be added to the API in some way as opposed to making them proprietary to the A10 provider. That would also resolve the issue.
16:27:18 <johnsom> Our guidance has been if the feature is something common across multiple providers, it should be considered for an API expansion.
16:27:48 <johnsom> Though that may not cover all use cases....
16:28:43 <johnsom> Does anyone else have thoughts on this topic?
16:29:26 <gthiemonge> I'm not too familiar with the flavor/flavor-profile API :/
16:30:20 <gthiemonge> could we apply it to the amphora driver?
16:30:34 <gthiemonge> switching topology?
16:30:51 <johnsom> I wrote a very nice guide:
16:30:52 <johnsom> #link https://docs.openstack.org/octavia/latest/admin/flavors.html
16:30:54 <johnsom> grin
16:31:06 <johnsom> Yes, it already includes topology for the amphora provider
16:31:07 <gthiemonge> I probably already read it :D
16:31:52 <gthiemonge> I mean switching topology of an existing LB
16:32:16 <gthiemonge> or updating the compute flavor
16:32:20 <johnsom> Ah, well, currently no, it's immutable after an LB is deployed.
16:32:29 <johnsom> That would all be new.
16:33:32 <johnsom> One idea would be to allow updating the flavor profile. Maybe add to the flavor validation API support for the provider saying yes/no to some options being updated when the profile is in use.
16:34:40 <johnsom> Another would be allow updates to the flavor profile, add an interface for the providers to "figure out what to do with the new information". Something like, here is the new profile and a list of LBs, now you figure it out.
16:35:14 <johnsom> haleyb The OVN provider doesn't use flavors today, correct?
16:35:25 <haleyb> not that i know of
16:35:47 <johnsom> Yeah, so not your problem yet. grin
16:36:18 <johnsom> Any other ideas to consider?
16:36:53 * haleyb has enough problems :p
16:37:13 <cgoncalves> what happens LBs which providers cannot enforce the new flavor configuration settings?
16:38:00 <johnsom> I would assume that the flavor validation in the provider would fail and the operator would get told "Nope"
16:38:00 <cgoncalves> for example, the topology of amphora LBs is updated but the amphora provider cannot apply it without delete/create?
16:38:16 <cgoncalves> OK, I like that
16:38:48 <johnsom> Yeah, we would have to add a "validate for update" or something similar to how we validate on create today.
16:39:58 <johnsom> #link https://github.com/openstack/octavia-lib/blob/master/octavia_lib/api/drivers/provider_base.py#L480
16:41:57 <johnsom> Ok, so next steps... I would propose (though I'm not the current PTL) we start a spec proposal that can capture the use case(s) and start capturing the ideas of how to solve in the "Alternatives" section. This way we can discuss in gerrit comments, etc.
16:42:03 <johnsom> #link https://github.com/openstack/octavia/blob/master/specs/skeleton.rst
16:42:26 <johnsom> Basic instructions are here:
16:42:28 <johnsom> #link https://github.com/openstack/octavia/blob/master/specs/template.rst
16:42:55 <johnsom> How does that sound ht-a10?  Did you have more on this topic?
16:43:01 <cgoncalves> +1. a spec would help us discuss and document for reference to other providers
16:43:17 <ht-a10> That works for me! Thanks
16:43:42 <johnsom> ht-a10 Also, welcome to the Octavia community. It's excellent to have A10 active again.
16:44:05 <ht-a10> Thank you! Glad to be here
16:44:19 <cgoncalves> +1000!
16:44:37 <johnsom> Ok, let's move forward that way. This will also help with rm_work's scheduling issues.
16:45:01 <johnsom> #topic Open Discussion
16:45:05 <johnsom> Any other topics today?
16:45:16 <haleyb> just a plug for a patch
16:45:28 <johnsom> Link away....
16:45:37 <haleyb> https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/745962 - it has two +2's but noone wants to push it in the gate :)
16:46:37 <haleyb> oh, and i did have one more topic i'm just remembering...
16:46:50 <johnsom> Yeah I have already +2'd that. Maybe gthiemonge can also review?
16:47:07 <gthiemonge> johnsom: haleyb: I can
16:47:52 <johnsom> haleyb What is the other topic?
16:47:53 <haleyb> there are some tests in our tempest repo for SOURCE_IP_PORT which are obviously skipped by in-tree stuff, any problem adding tests specific to that?
16:49:07 <haleyb> i'll be looking at OVN provider coverage, and whether to create yet another tempest repo, would rather keep them in one place if they are generic enough
16:49:08 <johnsom> I don't follow the question. If there are already tests what needs adding?
16:49:36 <haleyb> johnsom: i don't know what needs adding (yet)
16:50:02 <haleyb> maybe it's better to have any patch speak for itself
16:50:14 <johnsom> So, if the tests are testing Octavia, sure they go in the octavia-tempest-plugin repo. If they are provider specific, they should be in a provider repo.
16:51:11 <johnsom> Another example is, the tests in octavia-tempest-plugin should not require the OVN provider be enabled.
16:51:26 <johnsom> Or any other third party provider
16:51:42 <haleyb> johnsom: agreed, it's more at the algorithm coverage
16:53:28 <johnsom> Yeah, the recent test changes broke out the algorithms to each be tested. Since "Octavia" supports the algorithm, it should be included in the test suite.
16:55:06 <haleyb> ack
16:55:52 <johnsom> Ok, cool. Can't hurt to propose a patch. Worst case you can cut/paste to another repo. grin
16:56:47 <johnsom> Any other topics in our last four minutes?
16:56:53 <johnsom> Three I guess.
16:57:59 <johnsom> Ok, thank you all! Have a great week.
16:58:02 <johnsom> #endmeeting