Open Stack

To add insult to injury, the services that would benefit the most (think
nova) would require the most work.
And, since the goal is to have NATS support and not remove eventlet
(because there is like no force to do it now), it seems best to focus on
porting NATS support to eventlet.

On Fri, 21 Jul 2023 at 23:31, Tobias Urdin <tobias.urdin at binero.com> wrote:

> Hello,
>
> And just to iterate on this, just look at the code duplication (double the
> maintenance for an async and sync with eventlet code path).
> review.opendev.org <https://review.opendev.org/q/topic:asyncio-nats>
> <https://review.opendev.org/q/topic:asyncio-nats>
> <https://review.opendev.org/q/topic:asyncio-nats>
>
> We’d need to duplicate oslo.service, oslo.messaging and all other common
> libraries being called in a asyncio code path, and not only
> that we’d need to consolidate everyone on a Pecan (REST API library)
> replacement that would support asyncio (a new oslo library?) and
> just imagine that migration and consolidation effort for multiple projects.
>
> Even then we’d also need to port every single project to using it without
> regressions in performance.
>
> It’s a crazy massive effort, but I fully agree that eventlet should have
> been gone long ago.
>
> Best regards
> Tobias
>
> On 21 Jul 2023, at 16:16, smooney at redhat.com wrote:
>
> On Fri, 2023-07-21 at 15:40 +0200, Thomas Goirand wrote:
>
> On 7/21/23 13:32, smooney at redhat.com wrote:
>
> On Fri, 2023-07-21 at 11:59 +0200, Radosław Piliszek wrote:
>
> On Fri, 21 Jul 2023 at 09:03, Thomas Goirand <zigo at debian.org> wrote:
>
>
> On 7/15/23 16:27, Tobias Urdin wrote:
>
> The effort is mostly now to get/find a supported third-party Python
> library that does not
> use asyncio for usage in a oslo.messaging driver.
>
>
> Sorry to ask, but what's the problem with asyncio? Do we want something
> *not* async? If yes, why?
>
>
> Large swaths of OpenStack code are not ready for async.
> We want to take baby steps and get to some better place with tangible
> benefits.
>
> that not entirly correct.
> much of openstack is already async but we made a decision ot use eventlet
> as our async model many many
> years ago after we ported form twisted.
>
> The problem is you cannot really mix eventlet code and asyncio safely in
> the python process.
> That means you cannot have the async nats lib used in
> nova,swift,cinder,neutron, glance and progrably other
> projects today.
>
> i proposed one option a long time ago which is to take a privsep like
> approch where we spawn the oslo messaging
> driver
> into a sperate process and comunicate with it over a unix socket.
>
>
> IRRC, back in 2014, at the Hongkong summit, there was a large consensus
> that Eventlet was a wrong choice. I can still remember Jay Pipes
> shouting "die Eventlet, die...". Fast forward nearly 10 years later,
> nothing has moved in that direction, and we're still stuck with that
> horrible hack. Why don't we just get rid of Eventlet and switch to
> asyncio instead? That'd be a *HUGE* improvement in terms of ... well
> many things ... less bugs, more maintainability, less breakage on each
> minor Python release, etc. That'd be a lot of work, I'm sure... At the
> same time, everyone would be happy to finally get rid of it.
>
> we have consider that in the past and the reality is it would be a massive
> rewrite
> we considerd doing this when we were dicussiong moving to python3 and at
> various points since
> the problem is two fold. 1 we dont have contibutors able to work on this
> currently. 2 we dont have
> a good solution for how to do this incrementally.
>
> in nova at least we did breicly consider tyring to add asyncio
> console-script entries points
> so that we couuld have an eventlet version and non eventlet version of
> each service to act as a bridge
> its somethign we could discuss again but makign such a change without
> introducing bugs or performance regressions
> would require a lot of careful engenieing work.
>
> i would love to regarin the ablity ot run nova under a debugger and drop
> the dep on eventlet but i dont want
> to do that at the expense of stablity or perfromace for our customer.
>
> some services liek the api and schduler would be relitivly simple to port.
> the compute agent and conductor on the other
> hand rely on the implict acync behavior to fucntion at all. nova-comptue
> with libvirt as at lest 3 while true loops
> to compunticate with rabbit, libvirt and privsep to name just one of the
> the issues tha towuld need to be resolved.
>
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230722/6e10a2c5/attachment.htm>