Hi, 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. 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. 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. 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? 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? Does the infra team has time for this? 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?
- 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...
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. Cheers, Thomas Goirand (zigo)