Hey

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! :)

I was exactly trying to explain that our points would have valid differences.

You are right that it does not change much on the packager side. But in my eyes it should change a lot on the user side. When 2 different projects depend on a single library (i.e. libssl) of different versions you should not have a bigger problem when updating this lib, since Rust project is compiled with hopefully a certain supported version. From what I read about the debian Rust packaging process is that it is expected to have crates in many different versions available as packages exactly to address that. You, as a user, will not have a broken runtime system just because dependency was updated for the other project. From my point of view the constraints issue in runtime is addressed with that. Am I wrong here?

The big difference between python and rust in transitive dependencies version handling is that rust allows you to have multiple versions of a single transitive dependency during the compilation. This is, however, exactly what makes my life in the python world a nightmare when updating transitive dep in constraints for the need of one project breaks some other dependency.

> 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?

Valid points. Actually pretty much everything you have mentioned is valid on its own and makes sense. It can be implemented either way. It depends on the technical feedback and ideas we can gather from vendors and CSPs. It was removed from the summary email (not to give food for concerns), you can read details in the [PTG etherpad](https://etherpad.opendev.org/p/oct2025-ptg-keystone) for options and potential strategy. You could route v3 to the left and v4 to the right, you can have only rust doing the proxying and internally forward requests to v3 (addressing the wsgi issues we have). Regarding the endpoint: current implementation that I was using during the demo in talk on summit is that version discovery is served by the Rust and shows v3 as stable and v4 as experimental (pointing at different url). Version discovery standard is there to address it without introducing new endpoint/service

We explicitly gather feedback and ideas.

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.

The reason for the message was to raise awareness. As also mentioned - there were provisional commitments from vendors and csps to contribute and we now wait to see how it evolves.

We now also have problems with contributors in python, ...

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. :)

:) Using it on a daily basis I see so many problems we have in python that are conceptually not possible in rust. It is not an easy language, and from experience I can say here with absolute confidence - without knowing this language it is impossible to judge what is possible and what not and to estimate which kinds of problems would have been prevented.

Regards,

Artem