15:12:24 <hberaud> #startmeeting oslo
15:12:24 <opendevmeet> Meeting started Mon Sep 19 15:12:24 2022 UTC and is due to finish in 60 minutes.  The chair is hberaud. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:12:24 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:12:24 <opendevmeet> The meeting name has been set to 'oslo'
15:12:37 <hberaud> Courtesy ping for hberaud, bnemec, johnsom, redrobot, stephenfin, bcafarel, kgiusti, jungleboyj, gmann, tobias-urdin
15:12:45 <johnsom> o/
15:12:48 <hberaud> #link https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting
15:13:23 <hberaud> As I'm not the meeting facilitator, let's move directly to the NATS topic
15:13:30 <hberaud> #topic NATS driver – moving forward and future of eventlet
15:13:51 <tobias-urdin6> yeah, just to start things off, i think we can all agree that using the official nats-py library is the only way forward for getting it in
15:14:04 <hberaud> +1
15:14:14 <damani> hberaud, yes
15:14:16 <damani> sorry
15:14:26 <tobias-urdin6> so the real question becomes how should we go on about that, so, how do we go forward with that?
15:14:53 <opendevmeet> damani: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
15:15:05 <tobias-urdin6> running the driver in a separate thread due to needing asyncio, anybody have any ideas?
15:15:13 <damani> sorry
15:15:14 <hberaud> damani: the meeting is already started...
15:15:20 <damani> you have already started
15:15:22 <damani> yes
15:15:41 <tobias-urdin6> this discussion will probably be a lot of overlap into the "how to use asyncio" in the openstack eco system
15:16:13 <tobias-urdin6> so i'm interested in where we should initially place our focus, how we should prioritize our time moving forward, whats steps do we need is what we need to figure out
15:16:31 <hberaud> yoctozepto proposed to start migrating blazar (a simple project, more simpler than nova) to asyncio first and then start using the nats driver with asyncio
15:17:02 <hberaud> so with this solution we won't have to run IPC to RPC
15:17:20 <hberaud> we will use NATS directly
15:18:03 <hberaud> and, I think, that could help us to design a process to help migrating from evnetlet to asyncio
15:18:13 <johnsom> Are the discussions that all projects should move, like a community goal? Or is this an opt-in if you want it? I was expecting this was an opt-in change.
15:18:14 <hberaud> (for the other services)
15:19:11 <tobias-urdin6> johnsom: we are just brainstorming now pretty much, but I think it's in the communities interest to consider
15:19:45 <johnsom> That said, moving off eventlet is a worthy goal. I.e. https://review.opendev.org/c/openstack/designate/+/856313
15:19:51 <felixhuettner[m]> just for consistency it might make more sense as a community goal (if the move proves worthwhile)
15:19:56 <hberaud> IMO I think we should found/write/design an "how to" migrate from eventlet from asyncio
15:20:04 <hberaud> (first)
15:20:15 <johnsom> +1 to hberaud
15:20:37 <tobias-urdin6> some links where brought up about eventlet being mostly stale in https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.2022-09-02.log.html
15:20:50 <johnsom> Goals that are put in place before there is enough supporting libraries and documentation do not go well.
15:20:54 <hberaud> and then migrate blazar in parallel during the implementation of the NATS driver
15:21:59 <hberaud> moving away eventlet is clearly a community goal, but I think the blazar migration could be a POC
15:22:22 <hberaud> before officializing this goal as a community goal.
15:22:23 <johnsom> +1
15:22:36 <tobias-urdin6> so what are potential blockers, are we talking about asyncio support for oslo.db and an asyncio oslo.messaging executor to migrate blazar?
15:22:38 <hberaud> We could bring some guidance and adivces
15:23:06 <hberaud> no I don't think
15:23:36 <hberaud> whatever...that's a good question...
15:23:52 <hberaud> oslo.db seems already compatible
15:24:00 <hberaud> AFAIK
15:24:47 <hberaud> however if we transition blazar first, then I think that mean that we should also transition the oslo.messaging executor...
15:25:16 <hberaud> without even starting to use the NATS driver...
15:25:43 <hberaud> so, I think the NATS driver should be ready before blazar
15:26:11 <hberaud> and during the transition of blazar we should switch the driver
15:26:15 <hberaud> thoughts?
15:26:56 <hberaud> does the snake bite its tail?
15:27:08 <tobias-urdin6> hm
15:27:31 <yoctozepto> o/
15:27:42 <yoctozepto> sorry for being late, my calendar reminder failed
15:28:23 <hberaud> np
15:28:53 <felixhuettner[m]> or would we rather need the amqp driver to be asyncio-ready as well
15:28:54 <tobias-urdin6> so, an asyncio oslo.messaging executor, nats driver with nats-py and get oslo.db working (or verify it works) and run devstack with both nats and rabbitmq where blazar uses nats
15:28:57 <felixhuettner[m]> to skip this dependency
15:29:06 <tobias-urdin6> would that be correct?
15:29:42 <hberaud> At first glance yes, that looks correct
15:29:42 <felixhuettner[m]> sound good for me
15:29:57 <yoctozepto> mhm
15:30:31 <yoctozepto> or are we ready to roll out a rmq/amqp-compatible asyncio driver?
15:30:43 <yoctozepto> as to avoid too many moving parts
15:30:58 <yoctozepto> ignore if it is similar workload to adding nats support
15:31:48 <tobias-urdin6> ok, so I found a very old poc in incubator for tullip oslo.messaging executor that is some predecessor (with some others) to the asyncio implement iiuc, not that it's working or complete but atleast a template https://github.com/markmc/oslo-incubator/blob/8509b8bf7220605143dff149a4e32a923d0ead02/openstack/common/messaging/_executors/impl_tulip.py
15:31:53 <hberaud> tobias-urdin6: running devstack with both nats and rabbitmq, you mean with blazar?
15:32:10 <tobias-urdin6> not sure, we'd need to dig more into details about rabbit support for asyncio i guess
15:32:32 <tobias-urdin6> hberaud: yeah, like blazar uses rpc over nats and all other openstack services use rabbitmq
15:32:46 <hberaud> ok, then sound good
15:32:55 <tobias-urdin6> the devstack plugin i wrote now just plain off disables rabbitmq so need to remove that
15:33:23 <yoctozepto> ++
15:33:43 <yoctozepto> we need rmq to pass CI because blazar depends on nova
15:33:59 <felixhuettner[m]> at least the kombu library we use does not support asyncio yet: https://github.com/celery/kombu/issues/879
15:34:01 <hberaud> tobias-urdin6: yes I don't think we want to spend time with rmq and asyncio into the related O.M driver
15:34:23 <yoctozepto> ack, so let's go with oslo.messaging(asyncio+nats)
15:34:53 <tobias-urdin6> i'm however not sure if we need some kind of changes in oslo.db for the sqlalchemy part tho but i guess we'll find out
15:35:06 <yoctozepto> I don't know either
15:35:11 <yoctozepto> hoping not too many
15:35:19 <hberaud> yeah...
15:35:37 <tobias-urdin6> sound like a plan atleast, if we'd get that working, we have another nest with taskflow/futurist part but we are spared since blazar doesn't use those part (except oslo.messaginge executor from futurist used today)
15:35:38 <hberaud> Apparently that seems "ready" (by reading the doc)
15:36:37 <yoctozepto> yup
15:36:50 <yoctozepto> hberaud: what looks "ready"?
15:37:04 <hberaud> Last week I tried to identify existing tuto/doc/data that could be useful and used during the blazar transition
15:37:45 <hberaud> yoctozepto: supporting asyncio
15:38:16 <yoctozepto> hberaud: that I got but where?
15:38:17 <tobias-urdin6> felixhuettner[m]: ack, that won't be fun, we'll probably have a hard time convincing projects to take action unless default oslo.messaging driver becomes nats then
15:38:22 <yoctozepto> as we mentioned a couple of projects
15:38:26 <tobias-urdin6> but atleast we can make this a poc
15:38:57 <yoctozepto> hberaud: and what have you found regarding tutos and docs?
15:38:58 <hberaud> yoctozepto: sorry I was thinking only about sqlalchemy
15:39:02 <yoctozepto> ah
15:39:04 <yoctozepto> ok
15:39:20 <hberaud> you're right oslo.db would surely require changes too
15:39:32 <tobias-urdin6> do we want to start an etherpad and collect all links and docs or just use some existing?
15:39:40 <tobias-urdin6> hberaud: yeah i think so
15:40:05 <yoctozepto> yeah, we need an organisational scratchpad
15:40:06 <hberaud> tobias-urdin6: an etherpad could be useful
15:40:09 <yoctozepto> so etherpad will do
15:41:15 <tobias-urdin6> i don't have enough insight into oslo.db but perhaps we can abstract away some asyncio parts for projects there when we run into them
15:42:04 <hberaud> LGTM
15:42:18 <yoctozepto> makes sense to me
15:42:45 <hberaud> let's focuse on O.M and Blazar first and then address the O.db things
15:42:54 <tobias-urdin6> +1
15:44:48 <hberaud> We could start with 1) the "blueprint" part on one side, 2) check for examples of projects who already migrated from eventlet to asyncio 3) start the blazar migration to asyncio
15:44:59 <hberaud> (O.M blueprint)
15:45:18 <yoctozepto> +1, good plan, all 3 can start parallelly though
15:45:24 <yoctozepto> AFAIAC
15:45:50 <hberaud> https://review.opendev.org/c/openstack/oslo-specs/+/692784
15:46:04 <hberaud> do we want to reuse that one ^?
15:46:36 <tobias-urdin6> https://etherpad.opendev.org/p/oslo-asyncio <-- a start?
15:46:37 <hberaud> or start with a new one fresly created and give a reference to the old one?
15:47:07 <yoctozepto> hberaud: start with a fresh one, we can copy some contents though as we see fit
15:47:25 <hberaud> ok
15:47:28 <hberaud> WFM
15:47:36 <tobias-urdin6> think ^ would be easier to see comments etc
15:47:47 <hberaud> ok
15:48:03 <hberaud> tobias-urdin6: what do you mean? => "Update NATS driver to use nats-py"
15:48:10 <hberaud> you mean creating?
15:48:20 <hberaud> the nats driver doesn't yet exist
15:48:58 <hberaud> Ok I seen your latest changes on the etheroad
15:49:01 <hberaud> pad
15:49:47 <tobias-urdin6> yeah so earlier patchsets already used nats-py, so perhaps we can use https://review.opendev.org/c/openstack/oslo.messaging/+/848338 as template
15:49:56 <tobias-urdin6> otherwise we'll just start from scratch and copy, same there, as spec
15:52:37 <hberaud> LGT%
15:52:39 <hberaud> M
15:53:21 <hberaud> let's resuse the existing stuffs
15:54:57 <hberaud> what pace should we have for our next meetings?
15:55:27 <hberaud> I'd suggest speaking about NATS each 2 or 3 weeks. Thoughts?
15:56:15 <hberaud> Do we want to run our own meeting to avoid similar issue than today?
15:56:26 <tobias-urdin6> sounds good, anybody interested in volunteering for any of the parts in the plan?
15:56:33 <yoctozepto> a dedicate asyncio meeting sounds good
15:56:43 <yoctozepto> dedicated*
15:56:46 <hberaud> +1 for a dedicated meeting
15:56:46 <tobias-urdin6> works for me, i don't really have a preference
15:56:51 <yoctozepto> every 2 weeks makes sense to me
15:57:36 <tobias-urdin6> do we prioritize getting a poc working or do we want specs? i would rather see a working poc than specs tbh
15:57:55 <hberaud> tobias-urdin6: do you want to become our chair meeting for this topic?
15:58:08 <hberaud> the POC LGTM
15:58:39 <tobias-urdin6> sure can do depending on time/day tho
15:58:43 <yoctozepto> PoC makes sense to prioritise over exact specs
15:58:56 <yoctozepto> but refreshing a spec skeleton would not hurt...
15:59:15 <hberaud> I'm volunteer to refresh the specs
15:59:49 <hberaud> to keep a trace of our related researchs and discussions
16:01:49 <hberaud> Ok, I think we reached our meeting timeslot end
16:02:15 <tobias-urdin6> ack, we'll i'm a little bit interested in getting started on a oslo.messaging executor unless anybody else want it
16:02:35 <yoctozepto> I'm interested in looking into blazar's deps on eventlet closer
16:02:36 <hberaud> That's sound like a plan
16:02:39 <tobias-urdin6> i think the messaging driver parts is more a refactor to a working state with nats-py
16:02:55 <hberaud> yes
16:03:25 <hberaud> good we have people almost on each topics
16:04:02 <tobias-urdin6> good, do we set a new meeting slot or take offline on ml
16:04:24 <hberaud> I put my name on the etherpad into the lines that interested me
16:04:40 <yoctozepto> offline
16:04:48 <hberaud> as you want
16:04:59 <hberaud> offline lgtm
16:05:20 <tobias-urdin6> works for me, thanks for today
16:05:30 <yoctozepto> thanks
16:05:38 <hberaud> that was a productive meeting, thanks everyone!
16:06:04 <hberaud> Anything else before I close the meeting?
16:06:18 <tobias-urdin6> not from my part
16:06:48 <hberaud> ok thanks everyone
16:06:50 <hberaud> #endmeeting