Before reading my answer: please keep in mind that I'm very enthusiastic about such move. Never the less, I have still a lot of questions for you, but none should be taken negatively.
Thank you very much for the very explicit clarification, it really helps a
lot. Same is valid for my answers.
On 11/6/25 4:26 PM, Artem Goncharov wrote:
- A nice coincidence is a freshly sent announcement from Debian that introduces a strong rust dependency in the packaging tooling, stating something similar to: either you work to comply with this requirement in the next 6 months or sunset the port [5].
Just like Jeremy wrote: this was *not* an announcement. It was a post written by a Canonical employee that has the mission (from Canonical) to rewrite stuff in Rust. He alone felt it was ok for him to impose a Rust rewrite of APT, even though some of the unofficial ports aren't ready yet with the Rust stack.
While I think it may be a nice idea to rewrite things in Rust, I don't think APT has any performance issues, and never had any memory issue. So I'm unsure what is Julian is trying to achieve.
got it, wasn't the best decision to mention it. But it shows that any change (or no change) in a community leads to opposition, just like it was with systemd, pulseaudio, you name it.
I am very much frustrated that you seem to be having the same approach: announcing what you want to do, or have already done, instead of discussing the mater with the wider community.
It is not the case. I announced my plans and discussed this already during the last PTG and even earlier within the Keystone team.
While I do like the idea of having a super-performing Keystone in Rust, I am sure there are better ways to move the OpenStack project in such direction. Why didn't you discuss this *before* writing the first line of code?
When you go to the Shark Tank/Dragon's Den show you need to prove your idea is working to get support. Nobody supports just an idea nowadays. Not in my surroundings. But really, since I see this type of statement not the first time (and please do not take it personally), is it so normal nowadays to "criticize" people for writing code to prove the idea? I want to solve the problem and not spend years in discussions on what could be "acceptable" by others. Anyway, I am a supporter of the "every tool has its own specific use case" philosophy, there is nothing universal out there.
I also remember the Swift project willing to start using Go. At the time, the Swift team was told that it would be ok if they spent a large amount of time making sure the infrastructure (ie: the CI, gating and all) would be ok for Go.
Are you willing to spend such time with the infra team?
We are not there yet. It is not even clear whether OpenStack is ever going to be there, so this is just a pure speculation at that time. But to answer your question - yes, if necessary and accepted by the community I am ready to spend time adding new jobs for Rust. Go example feels weird, to be honest, work has been done and there is not a single project using it now. Perhaps this is worth a separate analysis. As mentioned initially - we are not requesting Rust to be accepted now, but announce a work on a Rust project and the community may benefit from it being considered as official. But it is not a must now.
Also, you've blame some of the Python libs Keystone depends on. How can we make sure the same wont happen with the Rust things you'll depend on? Are all the Rust dependencies you depend on already in Debian, Ubuntu and Red Hat?
Valid points, you can never be sure, in nothing actually, not even in native libraries of the language itself. We have seen it also in python (some examples are crypt, setuptools support). I have tried to do wider analysis and rely on the libraries with the most healthy activity and wide adoption, used by big players (tokio, axum, sea-orm). I am not that familiar with the packaging requirements of Debian for Rust project, so I can't answer your questions precisely. While I believe I understand your points pretty well, I do not think this should be something that a regular maintainer of a certain random project should focus on. Every distro is coming with its own rules and processes and if one would want to keep everybody happy no development should ever happen. I personally think Rust makes the situation a bit easier (while perhaps requiring a certain number of initial changes in the processes) due to the static linking - it does not matter which dependency versions are installed at the user's OS, what matters is which versions were used during compilation. It is a dependency hell during the build, but not during the runtime. But you may have different valid opinions on this. No offence or blame!
- Keystone is a very sensitive component and in our eyes that fully justifies use of rust to provide a much stronger security on the language level.
There's been a few security issues with Keystone in the past. None of them were due to the language choice. I'm not buying into this at all. Performance, yes...
There were few, in my opinion, not directly in Keystone, but in the keystonemiddleware, but I do not want to bike-shed on this. I experienced (and fixed myself) plenty of flow and logic bugs in multiple projects that would have been prevented by Rust. Correct - performance improvement is big. Btw, that is also a reason for implementing before (or in parallel to) talking - you can't prove the performance improvement initially, now I can do this.
2. Do you deprecate python Keystone. - No - v3 is there, and we continue maintaining it
Does the Rust implementation already has *all* of the current v3 support? I wouldn't like having to deploy *2* Keystone. I'm also very much worried about the move to a v3, and what kind of migration effort this will push on all projects. I do remember that the switch from Keystone v2 to v3 was *very* painful and took really too long.
We tried to be as precise as possible, but apparently still not enough (I assume your mistyped v2 and v3 instead of v3 and v4). Few thoughts from me personally not representing the team anymore: - it was explicitly stated that KeystoneNG is an "extension" and not the replacement. Folks actually convinced me to state it this way not to be crucified immediately. - we discussed potential evolution and how to implement migration strategy with implementing (integrating) parts of existing v3 into NG to simplify migration. But the message was and stays: nobody is rewriting Keystone in Rust for the sake of rewriting, or fun, we start with a new project that CAN be considered as a successor WHEN there is an interest. Regards, Artem