On 11/7/25 10:54 AM, Artem Goncharov wrote:
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!
IMO, that's a very common miss-understanding on how distros works. I'll speak for Debian, but Ubuntu and Red Hat have the same requirements. In distros, even in Go or Rust, each and every library is packaged separately. We do not accept libs to be "vendored". Well, there are a few exceptions, but at least, that's the global effort. This means that each and every library that you're going to (build) depend on will have to be in the distribution, so that at build time, your project can link against them. The fact that all is, at the end, statically linked, changes nothing to what I wrote above. The only thing it changes, is for people wishing to run binaries built outside of the distribution. So no, compared to the Python situation, it changes nothing (at least, from a package maintainer perspective). The only annoying thing for me: I will have to learn Rust packaging. Though this is probably a good thing! :)
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
I very much understand your point about not rewriting the v3 for the sake of it. It makes a lot of sense, and in fact, it's also probably avoiding some bugs where the implementation could have made small, undetected changes leading to hard to find bugs. So, if I understand you correctly: there WILL be a time where we'll be running both keystone and keystone-ng in a single deployment, where the Python one would handle v3, and Rust one handling v4. In such case, do you see them sharing the same port? Or maybe the Rust one forwarding the traffic to the Python version? How will this work? Will there be a new OpenStack endpoint for the Rust version? Last question: I did a git clone, and saw that all commits were from you. Is there others onboarding? Like Jeremy, I see Rust as possible blocker to get contributors (at last at first), and it's worrying if you're the only person pushing patches. Thanks for your work on this, and sharing your views, Cheers, Thomas Goirand (zigo) P.S: This project is one more new reason why I should learn Rust. :)