16:00:06 <johnsom> #startmeeting Octavia
16:00:06 <opendevmeet> Meeting started Wed May 28 16:00:06 2025 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:06 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:06 <opendevmeet> The meeting name has been set to 'octavia'
16:00:14 <gthiemonge> o/
16:00:22 <johnsom> Hi everyone
16:00:42 <johnsom> #topic Announcements
16:01:05 <johnsom> I don't think I have any announcements this week.
16:01:09 <johnsom> Anyone else?
16:01:15 <scoopex> gthiemonge: ah okay, i will read that. Missed it last week because of familiy issues...
16:01:20 <gthiemonge> johnsom: nop
16:01:37 <johnsom> #topic Brief progress reports / bugs needing review
16:02:06 <johnsom> As you have probably noticed, I have been focused on fixing our gates.
16:02:21 <johnsom> I was also on holiday this week.
16:02:52 <gthiemonge> same for me, holidays (+ downstream tasks)
16:02:59 <johnsom> Our gates are suffering from changes in setuptools, oslo.context, neutron, etc.
16:03:33 <johnsom> I hope I am getting close to having things functioning again. Sorry it's been slow going but fun issues keep coming up.
16:04:36 <johnsom> Oh and taskflow also broke us this week.
16:05:01 <gthiemonge> :/
16:05:06 <johnsom> So, that has been really all I have been able to focus on.
16:06:06 <johnsom> Ok, sounds like that is it. Moving on
16:06:19 <johnsom> #topic Open Discussion
16:06:24 <johnsom> Other topics this week?
16:06:34 <gthiemonge> nothing from me
16:08:11 <scoopex> Yeah, maybe the anti-affinity topic :-)
16:08:12 <johnsom> scoopex Did you want to discuss your topic more this week or wait until next week?
16:08:19 <scoopex> Yes :-)
16:08:43 <scoopex> https://input.scs.community/JgMcHJ8oQTKk0cC9UzgUjw# - My suggestion is based on the fact that we can simply pass a rule (possibly with a configuration value) into the created ServerGroup in Octavia. More should not be necessary in the Octavia code.
16:09:18 <scoopex> This filter can then react to the set value in nova.
16:09:43 <scoopex> A filter can then react to the set value in nova.
16:10:04 <scoopex> This can be a custom filter or a new Nova default filter that can be activated and used in Nova for antiaffinity, e.g. at AZ level or HostAggregate level.
16:10:21 <johnsom> So essentially we would add one new configuration setting in Octavia (default config and flavor likely) that would specify the anti-affinity filter to use in nova? Do I have this right?
16:11:30 <scoopex> We have to add a possibility to specify a rule name, which then is used as an name for the hostgroup.
16:13:44 <johnsom> So one new setting or two? I'm slightly confused on that.
16:15:09 <scoopex> Exacly one setting, we create the possibility to define a "rule name". (see https://docs.openstack.org/api-ref/compute/#create-server-group)
16:16:39 <johnsom> Yeah, ok, so we are thinking the same thing. I said "filter", but it's actual "rules".
16:17:06 <scoopex> The configure value can then be cosumed by a enabled custom filter (which filters out all unwanted hosts).
16:17:19 <johnsom> I don't think this would be a problem for Octavia. It should be fairly straight forward to implement.
16:18:05 <scoopex> I understand "filter" as the filter implementation in nova. https://docs.openstack.org/nova/latest/admin/scheduling.html#aggregateinstanceextraspecsfilter
16:19:40 <johnsom> Yeah, the rule would have to be implemented on the nova side somehow, to create the anti-affinity style you want (host, rack, room, az, etc.)
16:19:56 <scoopex> johnsom: the codechange in the octavia codebase should be small. I also liked the idea that scheduling things are handled in the nova scheduling context.
16:20:37 <johnsom> Yeah, so I don't see a problem with this idea.
16:20:53 <johnsom> Testing it may be a bit tricky though
16:21:46 <johnsom> I have no concerns with moving forward with a proposed patch.
16:21:57 <johnsom> gthiemonge Any thoughts on the topic?
16:22:29 <scoopex> Why is testing complex from for octavia? From the perspective of octavia it is only neccessary to test that a rule can be set.
16:22:47 <gthiemonge> nop, that looks interesting, maybe we could have a spec that describes the changes in the octavia API
16:23:26 <johnsom> The testing complexity is on the nova side. Multi-node gate jobs have been tricky to get right.
16:23:55 <johnsom> It might be a more flexible alternative to:
16:23:58 <johnsom> #link https://review.opendev.org/c/openstack/octavia/+/923939
16:24:41 <johnsom> gthiemonge Do you think we need a spec or is this small enough we iterate on proposed patches?
16:26:13 <gthiemonge> I'm fine if we iterate on patches
16:28:21 <johnsom> I agree, it's small so changing it should not be a major undertaking
16:29:01 <scoopex> As described, nova also provides the pssibility to write and activate your own filters. So one idea might be to implement temporary filter which only acts when a server was created from the ampora flavor. With that the idea might be testable without changes to the nova and octavia codebase.
16:30:40 <johnsom> Using a metadata on the image? (that's pretty much the only way it would know it's an amphora I think)
16:32:01 <scoopex> Probably. I might also possible to get the id of the flavor as an cirteria.
16:33:06 <scoopex> Sorry for the many spelling mistakes :-) Too many parallel topics today....
16:33:25 <johnsom> lol, same here, no worries
16:36:03 <johnsom> scoopex Do you have what you need from us on this?
16:36:24 <scoopex> Yes! Thanks!
16:36:34 <johnsom> Great!
16:36:40 <johnsom> Any other topics today?
16:36:44 <gthiemonge> nop
16:37:17 <johnsom> Alright, thank you everyone!
16:37:21 <johnsom> #endmeeting