On Fri, 21 Jul 2023 at 09:03, Thomas Goirand <zigo@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.
Unfortunately I didn’t get any feedback from the company maintaining the nats.py library on supported developer time implemeting the sync client feature, I assume (my view) that they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus) in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time effort into it.
Would it help if I was packaging NATS in Debian (and therefore, as a consequence, in Ubuntu)? By reading the go.mod, it feels like it has a reasonable amount of dependencies (though I didn't check for the indirect ones), so it feels like doable...
NATS's preferred way of delivery is a single (!) binary offered by the upstream. I guess you could help considerably with minimum effort by repackaging it into a deb so that users going for apt hunting get the upstream NATS. Then it would only boil down to finally packaging the Python library that works well with both OpenStack and NATS but we don't have it yet. Kind regards, Radek -yoctozepto