16:00:35 <gthiemonge> #startmeeting Octavia
16:00:35 <opendevmeet> Meeting started Wed Jul  6 16:00:35 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:35 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:35 <opendevmeet> The meeting name has been set to 'octavia'
16:00:39 <gthiemonge> Hi Folks!
16:00:48 <tweining> o/
16:01:03 <oschwart> o/
16:02:23 <gthiemonge> #topic Announcements
16:02:31 <gthiemonge> * New core reviewer in the Octavia group
16:02:43 <tweining> seems it's going to be a RH-internal meeting :)
16:02:46 <gthiemonge> Great news, tweining is now part of the core reviewer group for Octavia!
16:03:04 <gthiemonge> congrats and thank you for your work tweining ;-)
16:03:21 <tweining> yay, that's great. thank you for all your support.
16:03:34 <oschwart> Congratulations tweining!!!
16:04:36 <tweining> I already gave my first CR+2 and CR-2 ;)
16:04:42 <gthiemonge> any other announcements?
16:04:43 <gthiemonge> -2?
16:04:52 <tweining> the duplicate change
16:05:06 <gthiemonge> duplicate, ok
16:05:35 <matfechner> o/
16:06:00 <gthiemonge> #topic CI Status
16:06:11 <gthiemonge> FYI the functional job is broken because of an update of pecan
16:06:15 <gthiemonge> tweining has proposed a patch
16:06:25 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/848816
16:06:41 <gthiemonge> johnsom approved it few minutes ago, the gates should be fixed soon
16:07:16 <gthiemonge> the change includes an update of l-c.txt
16:07:28 <tweining> yes, next we will try to remove the l-c.txt
16:07:31 <gthiemonge> but I think that now, we need to merge the patch that removes that job
16:07:37 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/840108
16:07:44 <gthiemonge> yup
16:08:12 <gthiemonge> I will approve it whe nthe fix is merged
16:09:19 <tweining> btw. did we announce that registration for PTG is open?
16:09:33 <gthiemonge> nop, not yet
16:10:44 <gthiemonge> there was also an email for the team signup, I think I need to ping our contributors to know if they plan to go to Columbus
16:12:10 <tweining> yes, it would be interesting to know who plans to go there
16:12:49 <gthiemonge> yeah
16:13:00 <gthiemonge> #topic Brief progress reports / bugs needing review
16:13:16 <gthiemonge> no much activity from me, I've spent a lot of time on downstream issues
16:14:00 <gthiemonge> I know that we have a long list of backports to review, I hope I'll be able to review them before Friday
16:15:43 <spencerharmon> I'm just catching up on @tweining's comments regarding the documentation for notifications. I'm making those edits now. I'm unsure how to proceed about the default notifications.info topic. I haven't seen any documentation that oslo messaging is changing this behavior and in my lab environment, this topic is created.
16:18:01 <gthiemonge> spencerharmon: your lab env is devstack?
16:18:14 <spencerharmon> No, it isn't
16:18:52 <tweining> https://review.opendev.org/c/openstack/octavia/+/831051 for the record, this is the notifications change
16:20:06 <gthiemonge> ok, we could try to figure out why the notification queue doesn't get any messages
16:20:09 <gthiemonge> I will re-test it
16:20:14 <spencerharmon> Yes, thank you! I can work on setting that up, but my thought is that it's likely to result in the same behavior you both saw. In that event, I think the thing to do is to document this, right? Alternatively, I can see about adding logic to create this if it doesn't exist.
16:21:09 <gthiemonge> so, in my env, the notifications.info topic exists, but it doesn't get the messages
16:22:00 <spencerharmon> Makes sense. I suppose I could set this as a default if no topic is provided.
16:22:08 <gthiemonge> and it exists, maybe not because of octavia, but because of other services, I don';t know
16:22:44 <opendevreview> Spencer Harmon proposed openstack/octavia master: Add event notifications for load balancers.  https://review.opendev.org/c/openstack/octavia/+/831051
16:24:21 <gthiemonge> BTW, I forgot this topc, I recreated the review list:
16:24:31 <gthiemonge> #link https://etherpad.opendev.org/p/octavia-priority-reviews
16:24:50 <gthiemonge> you can change the priority/order of the items if you want
16:25:01 <gthiemonge> notifications is on top of the feature list
16:25:25 <spencerharmon> Top of the list is ok with me! ;)
16:25:47 <tweining> from my perspective the notifications change is okay as it is now
16:27:04 <gthiemonge> yeah I agree, except with this notifications.info topic ;-)
16:27:07 <spencerharmon> I have not concerns leaving it, but I'm also happy to investigate explicitly setting the default notifications topic to ensure it behaves the way I've documented.
16:27:30 <gthiemonge> spencerharmon: yeah that would be nice if you could take a look at it
16:27:52 <spencerharmon> It says "You may specify," but as is, you *must* specify.
16:28:33 <tweining> at least in devstack I tried both the default topic (which is notification) as well as setting the topic to notifications explictly. same result
16:29:37 <spencerharmon> I'll work on that. Don't worry about retesting until I get that in.
16:30:00 <tweining> cool
16:30:09 <gthiemonge> spencerharmon: ok thanks, don't hesitate to ping us before the next meetign if you have an update!
16:30:31 <tweining> also, we have about 2 month till feature freeze so there is no rush
16:31:01 <spencerharmon> Sure thing! I'll be out of town next week, but I'll let yall know once I have something for you to review on this issue.
16:31:55 <spencerharmon> Thanks for the reviews! :)
16:33:53 <gthiemonge> #topic Open Discussion
16:34:02 <gthiemonge> any other topics?
16:35:46 <tweining> hm, not sure. I'm working on a POC implementation for CPU pinning of HAProxy in the amp
16:36:55 <tweining> and I have one design problem. CW sends the rendered HAProxy.cfg to the API server on the amp.
16:37:27 <tweining> what I need is to get the number of vCPUs from the amp and add it in the config.
16:38:09 <tweining> so my idea was to extent the api so CW queries the number of vcpus from the API server on the amp before rendering the haproxy cfg.
16:39:16 <tweining> there are probably other ways to do this, but that seems to be the easiest way to me.
16:40:10 <tweining> but I didn't spend a lot of thought on it yet, so maybe it's a bit too early to discuss
16:40:12 <gthiemonge> there's an info endpoint in the amphora
16:40:18 <gthiemonge> https://opendev.org/openstack/octavia/src/branch/master/octavia/amphorae/backends/agent/api_server/server.py#L170-L172
16:40:41 <gthiemonge> https://opendev.org/openstack/octavia/src/commit/d590d6c7051a9d9941900efc85959e9158609e08/octavia/amphorae/backends/agent/api_server/amphora_info.py#L34-L45
16:40:51 <gthiemonge> I think it's pretty safe to extend it
16:41:33 <gthiemonge> but the worker might communicate with amphorae that do not include the new fields, so you have to take it into account
16:42:11 <tweining> I also need to generate another file on the amp, a file with variables for TuneD. for that I also need the number of vCPUs. I guess I can handle that entirely on amp side though.
16:42:52 <tweining> thanks, I will have a look
16:42:59 <gthiemonge> https://opendev.org/openstack/octavia/src/commit/d590d6c7051a9d9941900efc85959e9158609e08/octavia/amphorae/backends/agent/api_server/amphora_info.py#L47
16:43:04 <gthiemonge> this function incldues more info
16:43:13 <gthiemonge> but I don't think it is used by the controller services
16:43:14 <opendevreview> Merged openstack/octavia master: Add WebTest as an indirect test dependency  https://review.opendev.org/c/openstack/octavia/+/848816
16:43:31 <gthiemonge> yeah! gates are fixed^^
16:44:17 <tweining> :D
16:44:25 <oschwart> \o/
16:44:26 <spencerharmon> Woot!
16:44:52 <opendevreview> Gregory Thiemonge proposed openstack/octavia master: Drop lower-constraints.txt and its testing  https://review.opendev.org/c/openstack/octavia/+/840108
16:45:24 <gthiemonge> ^ merge conflict. tweining: could you review it again?
16:46:44 <tweining> sure
16:46:48 <gthiemonge> thanks
16:47:00 <gthiemonge> anything else folks?
16:47:13 <tweining> I don't think so
16:47:42 <oschwart> Nothing from me
16:47:49 <gthiemonge> ok!
16:48:00 <gthiemonge> well, thank you all!
16:48:09 <gthiemonge> #endmeeting