just to note what my plans are in this area, I intend to create an asyncio version of oslo.db enginefacade, which all openstack DB using projects are now using. the API will look just like that of https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/enginefacade.py except context managers will be async, and the session/connections passed around will be the SQLAlchemy async versions documented at https://docs.sqlalchemy.org/en/20/orm/extensions/asyncio.html .

Projects that wish to port portions of their code, or their entire code, to plain asyncio will be able to make use of oslo.db with this path, the only other requirement is that asyncio DB drivers would have to be used with this code. For SQLite there's aiosqlite https://pypi.org/project/aiosqlite/ which internally uses a thread per connection to create an asyncio effect, and for MySQL the driver we do best with is https://pypi.org/project/asyncmy/ , we also get good results these days from aiomysql https://pypi.org/project/aiomysql/ though it's had some maintenance bumps.

to support applications that use oslo.db in both sync and async ways I will likely introduce a new async-only database URL parameter, which if present will be used for asyncio versions of things. if it's not present then it can fallback to the main database URL which would need to refer to an asyncio driver.

On Tue, May 14, 2024, at 12:20 PM, Jay Faulkner wrote:

Hi all,

As you may have read in Goutham's TC summary, the existing eventlet goal[0] is unlikely to gain consensus to merge. This appears to be due to the difference in needs between OpenStack projects, and belief that it's unlikely a single solution would serve them all.

Our current situation is:

1) Eventlet usage must be discontinued. The temporary maintainers are just that -- temporary -- and we should not expect eventlet to continue to be a valid path moving forward.

2) We have basic agreement that shared tooling, such as oslo libraries, should not dictate a specific threading model.

In lieu of specific technical leadership and guidance from the TC, this leaves it to individual projects to decide what threading model to use instead of eventlet monkey patching. The unmerged spec[0] may be a good starting point if you're wondering where to start.

Importantly: do not let this work wait! It is a significant change and will take a long time to complete.

Thanks,

Jay Faulkner

0: https://review.opendev.org/c/openstack/governance/+/902585