16:00:29 <gthiemonge> #startmeeting Octavia
16:00:29 <opendevmeet> Meeting started Wed Nov  3 16:00:29 2021 UTC and is due to finish in 60 minutes.  The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:29 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:30 <opendevmeet> The meeting name has been set to 'octavia'
16:00:38 <johnsom> o/
16:00:40 <gthiemonge> hi!
16:02:25 <gthiemonge> #topic Announcements
16:02:35 <gthiemonge> well I don't have any annoucements
16:02:40 <gthiemonge> anyone?
16:03:01 <johnsom> I don't
16:03:37 <gthiemonge> #topic Brief progress reports / bugs needing review
16:03:55 <gthiemonge> I proposed a fix for a problem with some revert functions:
16:04:01 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/815973
16:04:34 <gthiemonge> in some tasks, in the revert function, we set the load balancer to ERROR and I believe that it is not good, because the provisioning_status of the LB acts as a lock on the resource
16:05:01 <gthiemonge> and in those revert functions, we unlock the LB too early, which may cause race conditions
16:05:06 <johnsom> Yep, unlocking too early
16:05:27 <gthiemonge> only the revert function of the first task of a flow (such as LoadBalancerToErrorOnRevertTask) should set a LB to ERROR in my opinion
16:05:44 <gthiemonge> I opened a story about the issue I got:
16:05:50 <gthiemonge> #link https://storyboard.openstack.org/#!/story/2009652
16:05:52 <johnsom> Yeah, it should roll up to the capstone task
16:06:58 <gthiemonge> please note that an additional patch will be required for release <=stable/wallaby
16:07:13 <gthiemonge> because some tasks were removed from Xena (spare pool)
16:08:27 <gthiemonge> and FYI I also started using centos 9 stream amphora images. It works in my local env, but not in the CI
16:08:49 <johnsom> Nice
16:09:04 <johnsom> On the Octavia front I have only been doing bug fixes
16:11:09 <johnsom> sigh, reviews that is
16:11:34 <gthiemonge> #topic 200 vs 202 return codes in the API
16:12:00 <johnsom> Yeah, this is my topic item
16:12:09 <johnsom> https://review.opendev.org/c/openstack/octavia/+/816393
16:12:29 <johnsom> This patch raised an interesting issue. No idea how it went this long without being caught.
16:12:56 <johnsom> Though I'm pretty sure we talked about this long ago. Maybe rm_work remembers the discussion
16:13:13 <johnsom> So, the API reference says that all of the PUT methods return 202 status codes.
16:13:45 <johnsom> This makes sense give that the updates are asynchronous, i.e. need to go update the certs in the amps.
16:14:01 <johnsom> However, the actual API code is returning a 200 code for these calls.
16:14:24 <johnsom> #link https://review.opendev.org/c/openstack/octavia/+/816393
16:14:33 <johnsom> If you need a reference to the meanings:
16:14:41 <johnsom> #link https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
16:14:59 <johnsom> The patch proposes simply changing the API reference to show 200's
16:15:33 <johnsom> However, I raised the question of should the API really be returning 202 since they are async methods.
16:16:08 <johnsom> Thoughts?
16:17:04 <gthiemonge> that's a good topic :D
16:17:30 <johnsom> lol, yes
16:17:56 <gthiemonge> AFAICT I see a lot of good reasons to reply 200 to these calls, and a lot of good reasons to reply 202
16:18:49 <johnsom> Yeah, one could argue for 200 as I think the response includes the updated fields (though PENDING_UPDATE status).
16:19:11 <johnsom> You could argue 202 because they are in PENDING_UPDATE and not yet actually applied to the LBs
16:19:11 <gthiemonge> one concern raised in the review about fixing the code and not fixing the doc is that changing the code may break some clients/sdks
16:19:28 <johnsom> 202 is kind of a signal that you should poll for status updates
16:19:47 <johnsom> Yeah, changing status codes is.... ugly
16:20:01 <johnsom> I don't think it will break openstacksdk or our client
16:20:36 <johnsom> Both should be looking for a 2xx code and not specific sub-codes
16:21:46 <gthiemonge> I didn't any clients/sdks in openstack that use the return code
16:24:02 <gthiemonge> i'm lazy so I would recommend fixing the doc :D
16:24:43 <johnsom> Yeah, this is one that is... unfortunate.
16:24:52 <johnsom> Maybe add it to the v3 api list
16:24:53 <gthiemonge> johnsom: but if you think that 202 is more appropriate, let's fix the code
16:25:13 <johnsom> I think the community should decide. I would like to hear what rm_work thinks too
16:25:27 <gthiemonge> do we have a v3 api todo list?
16:25:33 <johnsom> We should
16:26:01 <johnsom> Maybe we should create a wiki page
16:26:42 <johnsom> With a big warning at the top that v3 is not planned any time soon
16:26:50 <gthiemonge> +1
16:27:49 <johnsom> Ok, maybe we should table this topic and hope for more community feedback
16:28:08 <gthiemonge> yeah, async feedback
16:28:29 <gthiemonge> johnsom: thanks for raising this issue
16:28:38 <gthiemonge> #topic Open Discussion
16:28:45 <gthiemonge> Any other topics today?
16:29:01 <johnsom> I don't have anything
16:29:19 <gthiemonge> Ok!
16:29:25 <gthiemonge> Thanks everyone!
16:29:30 <gthiemonge> #endmeeting