15:00:33 <hberaud[m]> #startmeeting openstack-eventlet-removal
15:00:33 <opendevmeet> Meeting started Tue Dec 17 15:00:33 2024 UTC and is due to finish in 60 minutes.  The chair is hberaud[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:33 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:33 <opendevmeet> The meeting name has been set to 'openstack_eventlet_removal'
15:01:20 <amorin> o/
15:01:32 <hberaud[m]> Ping list: amorin, JayF, gouthamr, ralonsoh
15:02:00 <hberaud[m]> We are at line 90 https://etherpad.opendev.org/p/epoxy-eventlet-tracking
15:02:13 <hberaud[m]> Week R-15
15:03:27 <ralonsoh> hello
15:03:37 <hberaud[m]> o/
15:03:42 <hberaud[m]> ok let's go
15:03:55 <hberaud[m]> #topic Review task completion
15:04:10 <hberaud[m]> (amorin) keep track of the mistral failure on Eventlet requirements bump https://review.opendev.org/c/openstack/requirements/+/933257
15:04:38 <hberaud[m]> so thank you very much amorin for all the things you have done around mistral
15:04:49 <hberaud[m]> much appreciated
15:05:05 <amorin> I am still struggling on how to make mistral working with the last eventlet
15:05:07 <hberaud[m]> and the requirements bump's jobs are now green
15:05:11 <amorin> there is something I dont understand
15:05:31 <hberaud[m]> the floor is yours
15:05:39 <amorin> I am not able to get rid of all Rlock warning
15:05:50 <amorin> is it completely removed on other projects?
15:06:09 <hberaud[m]> no idea
15:06:22 <ralonsoh> I think in Neutron is monkey_patching just at the beginning
15:06:28 <ralonsoh> but I would need to review the CI logs
15:06:49 <ralonsoh> this happens when (1) monkey patch late or (2) monkey patch twice
15:06:54 <hberaud[m]> do you have a trace of these warning where I can take a look?
15:07:01 <amorin> I did try to monkey_patching once, at the beginning, but still failing..
15:07:25 <hberaud[m]> even with the last version of eventlet? 0.38.2
15:07:51 <amorin> not sure hberaud[m] , I will start again
15:08:07 <hberaud[m]> I'd suggest to open a github issue on the eventlet side
15:08:16 <amorin> anyway, on the other hand, I did try to reduce the usage of eventlet on mistral side, by switching to threading
15:08:31 <hberaud[m]> with your scenario and with some stacktrace
15:08:37 <amorin> oh, ok, will do then
15:08:38 <hberaud[m]> yes, thank you
15:08:47 <amorin> I had a reproducer last week with one the tests
15:09:06 <amorin> I even identified the commit in eventlet that was problematik, anyway, will do the github issue then
15:09:08 <amorin> thanks
15:09:21 <amorin> (I am done)
15:09:30 <hberaud[m]> Itamar is far well better than me on these RLock things, so maybe he could help us seeing more clearly
15:09:33 <ralonsoh> I think I commented that last week
15:09:49 <ralonsoh> that was the "last patch" related to rlocks
15:10:25 <ralonsoh> https://github.com/eventlet/eventlet/commit/06ec82896ebb9a26edaf6e1ad4d63393990f15b7
15:10:26 <hberaud[m]> ack
15:11:59 <hberaud[m]> we can pinpoint this change into the new issue
15:12:07 <hberaud[m]> anything else?
15:13:55 <hberaud[m]> so, concerning the masakari failures I raise the point on the ML
15:14:03 <hberaud[m]> https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/4RWJH7L7QWVO3SJ64MIGPUQ6Z4Q7HMYD/
15:14:24 <hberaud[m]> and we got no responses
15:15:17 <hberaud[m]> gouthamr: o/ should the TC relay on that point?
15:15:56 <hberaud[m]> and the last items from last meeting is " to check the neutron metadata wsgi server" assigned to myself
15:16:12 <ralonsoh> I've done it, I have a POC
15:16:17 <ralonsoh> with an embbeded server
15:16:25 <hberaud[m]> excellent
15:16:34 <hberaud[m]> and is work as you expected?
15:16:44 <ralonsoh> yes but we'll also need to have a multiprocess version
15:16:56 <hberaud[m]> ok
15:17:10 <ralonsoh> most probably we'll use the same workers architecture used in the Neutron API
15:17:19 <ralonsoh> but still working on this
15:17:43 <hberaud[m]> do you implemented it from scratch as you were thinking during our private discussion, or have you used something like gunicorn?
15:18:08 <ralonsoh> I'm not using an external process, I'm using socketserver
15:18:14 <hberaud[m]> (gunicorn or uwsgi, or whatever you want)
15:18:17 <hberaud[m]> ok
15:18:18 <hberaud[m]> cool
15:18:21 <ralonsoh> replacing the current eventlet.wsgi.server
15:18:26 <hberaud[m]> kudos
15:18:41 <hberaud[m]> great news
15:19:38 <hberaud[m]> anything else concerning that point?
15:20:02 <ralonsoh> no thanks
15:20:13 <hberaud[m]> ack thanks
15:20:15 <hberaud[m]> #topic update from HTTP/SGI working group
15:20:29 <hberaud[m]> so, no real update from working groups
15:21:33 <hberaud[m]> maybe I want to mention (for non redhatters) that we ran a downstream tour of teams and we have now a better overviews of patterns and impacts
15:22:04 <amorin> ack
15:22:32 <hberaud[m]> so early in 2025 we might craft some default proposals for each patterns
15:23:52 <amorin> I've been reading the wiki a lot to find example:
15:23:54 <amorin> https://wiki.openstack.org/wiki/Eventlet-removal
15:24:07 <amorin> I believe it's a good way to share best practices
15:24:11 <hberaud[m]> maybe Rodolfo's approach and glance their approach could be use cases that we could to lead other teams (one based on socketserver, the other on uwsgi), do not know. Lets see what happens
15:24:31 <ralonsoh> this is very specific implementation, for the metadata
15:24:40 <hberaud[m]> yeah but for now the wiki is a bit too much focused on asyncio
15:24:44 <hberaud[m]> ack
15:24:49 <amorin> it can still be referenced as an exemple
15:24:59 <amorin> it's usually very nice to see how others are implementing
15:25:08 <hberaud[m]> unfortunatelly asyncio cannot be applied on all our deliverables
15:25:12 <hberaud[m]> yes
15:25:48 <hberaud[m]> This is how I see the neutron example
15:25:49 <hberaud[m]> as an example
15:26:07 <hberaud[m]> more than a standard
15:26:12 <amorin> agree
15:26:34 <hberaud[m]> anyway, lets rediscuss it next year
15:27:19 <hberaud[m]> #topic update from task working group
15:28:01 <hberaud[m]> maybe we want to mention that the refactor of oslo.service is going and in good shape
15:28:10 <ralonsoh> good!
15:28:26 <hberaud[m]> Daniel proposed the internal mechanisms to implement backend
15:28:45 <hberaud[m]> He also moved the existing implementation into the eventlet backend
15:29:16 <hberaud[m]> And he started to deprecate the things that we want to remove (wsgi, sslutils, backdoor, fixtures)
15:30:13 <hberaud[m]> I think we will merge this first series of patches before starting the implementation of the threading backend
15:30:33 <hberaud[m]> this way we will be able to release a transient version of oslo.service
15:31:06 <hberaud[m]> and start to check that there is no regression in cross jobs
15:31:46 <hberaud[m]> #topic update from interoperability working group
15:32:59 <hberaud[m]> Concerning the interoperability working group, I think that we can mention that the new version of oslo.db is now out, and so the new asyncio engine facade is now available in oslo.db https://review.opendev.org/c/openstack/releases/+/937452
15:34:07 <ralonsoh> it works with eventlet too, right?
15:34:15 <hberaud[m]> yes
15:34:18 <ralonsoh> perfect
15:34:43 <hberaud[m]> yes it based on "awaitlet", so it is compatible with greenlet and eventlet
15:34:57 <ralonsoh> nice hybrid, btw
15:35:18 <hberaud[m]> I mean, the internal mechanism of sqlalchemy are tailored this way
15:35:31 <hberaud[m]> the oslo.db engine facade is just an exposure of these mechanisms
15:37:23 <hberaud[m]> and sqlalchemy support it since several years now, so, if we take into account popularity of sqlalchemy, I think if it would not have worked, we would have already informed since years
15:38:01 <hberaud[m]> and as this exposure is implemented by Mike itself, I think we can be confident
15:38:13 <hberaud[m]> s/itself/himself/
15:38:58 <hberaud[m]> #topic PTO and Christmas period
15:40:02 <hberaud[m]> Friendly reminder. There is no meeting during the 2 coming weeks.
15:40:17 <hberaud[m]> I'm on PTO and AFK during two weeks
15:40:38 <amorin> ack
15:40:52 <amorin> same here
15:40:57 <hberaud[m]> if someone want to volunteer to chair the meeting he is welcome, else there is no meeting
15:42:46 <hberaud[m]> and in the end it's not too bad because the first tueday of January is the second week of January
15:43:04 <hberaud[m]> so our meeting schedules are not impacted and our calendar remains ok
15:43:36 <hberaud[m]> so our next meeting is on Jan 7
15:43:55 <hberaud[m]> #topic Open Discussion
15:44:09 <hberaud[m]> Anything else that you want to discuss today?
15:44:30 <ralonsoh> no thanks
15:46:11 <hberaud[m]> calling one
15:46:21 <hberaud[m]> calling two
15:46:36 <hberaud[m]> calling three
15:46:49 <hberaud[m]> thanks everyone for joining
15:47:08 <ralonsoh> bye
15:47:15 <hberaud[m]> thank you for all the hard work made in 2024, and see you in 2025
15:47:24 <hberaud[m]> #endmeeting