> The work was done in Rust due to multiple factors: lack of necessary 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.
As stated initially - yes, we have this possibility when using Rust. Due to the heavy plugin architecture (what you refer separately) bindings are not that trivial, but it depends on the "entry point" of the binding.
To remind - we have a problem that certain things (saml) can be considered gone and we need to build the whole new federation logic around the oidc only giving users the control. So the reason is not the "rewrite", the reason is that features required an external work and the result of it looks very promising to be extended.
> 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.
It is interesting how the situation differs from cloud to cloud. Just not that long time ago (less than a year) we had a bug (
https://review.opendev.org/c/openstack/keystone/+/880456 for the fix) that a token validation request for the token issued for application credentials took 5-10x longer than the one for password. The commit message states around 400ms (on devstack), but in our public cloud it was 5s. And this is compared to something around 100ms for the password one (measures under real load). The "fix" is just caching the data that Keystone fetches over and over from the DB due to the current architecture.
Don't nail me on numbers, pls, it heavily depends on the environment and the use case, but token validation with rust takes without any caching 10-15ms on my laptop and on a VM with devstack
>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.
. The new stack makes it possible to execute queries in parallel. I do not know whether it is relevant for other services, but for Keystone it does. Current architecture does 60+ queries during a single request processing. Now we can control the data that we have already fetched (not based on the memcached) and send out some queries in parallel where the db schema requests multiple data sets.
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 :)
Please ask mentioned colleagues to step by and start participating, even if it is just in the discussions or issues regarding new features or the desired development direction. New features that I was presenting were focused on making operators and users happy. Having such feedback is making me feel like it was not a time waste.
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.
Maybe, I was also thinking about that, but didn't want to explicitly mention it.
Artem.