The work was done in Rust due to multiple factors: lack of necessary
Hi all, As a developer and the single maintainer of one of the OpenStack projects, I often feel bad when project owners propose something, try to move their service forward, and then hit a wall of community resistance. I believe maintainers/core developers should have the space to implement their vision. Without that, it is easy to lose interest, and then we end up retiring yet another project. So, from a developer's point of view: if the Keystone team believes Rust is the right direction, they should be able to move forward with it. I do not contribute to Keystone, so my personal opinion about Rust should not matter here :) But things change when I put on an Operator's hat. As an operator, I have a different view, and I feel bad that I'm leaning toward skepticism. I share Jeremy's concerns about the Swift and Skyline cases. I would also bring up the Glare project, which spun out of Glance with support from one or two original core developers (as far as I remember). We all know where Glance is today (it is here) and where Glare ended up (some people in this thread may not have even heard of it). We can also remember Nova V3 story. My main concern as an operator is simple: while Keystone may have only a couple of active core developers today, a very large number of people have contributed to the current Python codebase over the years. If something breaks (not a new feature), it can be relatively quick fixed because many people can still dig into the existing code in an emergency. A smaller concern: I like the current pluggable architecture. We use a small plugin to integrate Keystone with our internal environment, no patching required. I understand Keystone v4 is still early and may introduce a new plugin mechanism, but that uncertainty still raises some worry for me :) python libraries with trustable maintenance and/or licensing, necessity for enforcing security standards and practices using memory safe programming language Just curious, did you consider creating a Rust "binding" layer for Keystone instead of a full rewrite? That might address the Python dependency and maintenance issues you mentioned.
A side effect of it became immediately visible: performance. This allows us to achieve significant performance and maintainability improvements, eliminate the old ballast
From an operator’s perspective, Keystone performance has never been an issue for us. It just works. Thank you, folks! So if performance improvements are a side effect, great - but it has never been high on my list of concerns.
The new stack is fully async, uses parallel DB queries, and runs background tasks for periodic cleanups, synchronization, and similar.
This reminds me of the early async wave in Python. There were claims like “we built the fastest Postgres driver in the world,” but in practice, it did not noticeably change anything. I mean the problem quite often is not in the technological stack, but in the way people write software, which covers the dependencies and logical flow as well. Anyway, I would like to thank the Keystone team for the work you are doing and for opening this conversation. And to be fair, not all my colleagues share my skepticism - some of them can't wait for the new Keystone to be accepted so we can finally deploy it in our cloud :) At the same time, who knows - maybe part of the reason OpenStack struggles to attract new contributors is that most available Python developers are already here, and bringing in the Rust community could add some fresh air to the ecosystem. пт, 7 лист. 2025 р. о 18:55 Jeremy Stanley <fungi@yuggoth.org> пише:
On 2025-11-07 18:17:14 +0100 (+0100), René Ribaud wrote: [...]
I don’t know what the Foundation or the Technical Committee’s current position is on Rust within OpenStack [...]
The OpenInfra Foundation expresses no opinion in its bylaws, and while https://board.openinfra.org/en/ProjectGuidelines has been used for determining project suitability it only concerns itself with licenses and practices not choice of programming language.
The OpenStack Technical Committee does have published guidance about choice of programming language...
https://governance.openstack.org/tc/resolutions/20150901-programming-languag...
...as well as how to qualify new languages:
https://governance.openstack.org/tc/reference/new-language-requirements.html
An example is this resolution from when Go was added:
https://governance.openstack.org/tc/resolutions/20170329-golang-use-case.htm...
Introducing Rust would in theory involve a similar resolution, and "just" needs discussion and a vote among the TC members. -- Jeremy Stanley
-- Best regards, Andriy Kurilin.