On 10/9/25 16:31, Ivan Marton wrote:
>
> [...]
>> It seems to me that the underlying cryptography module does support
> pyca/cryptography/commit/51a6dd28ccbb7587fff9e951299b17aac39ee5cc>. That
> commit appeared in version 43.0.0 first. (In 2.7 that I see in https://
> was still not there. 2.7 was released on May 31, 2019, while 43.0.0 on
> Jul 20, 2024.)
>
> Is there chance to have that dependency being bumped up to some newer
> version?
You and Clark are correct, whether or not Nova supports the key types
depends only on the version of the Python 'cryptography' library
installed as it does not deal with the key types directly.
IMO we could bump the required version for release versions circa 2024
and newer. As long as 43.0.0 is available for install in the common
distros of the time.
version needed to use Nova in general, as using newer key types is not
strictly "required".
What really matters is the version indicated in the
master branch allows up to version 43.0.3 as of today. This version is
also shown as the upper bound for OpenStack versions 2025.2 and 2025.1.
Generally upper bound versions are selected within the range of the
common distros package versions at the time of that OpenStack release.
Note that I don't think you actually have to adhere to
deploy.
If you are able to install cryptography 43.0.0 in your environment, you
should automatically get Nova working with it (after service restart).
This was my experience anyway in the past with
-melwitt
[1]
Since the server-side environment is not under my control, all I could do is to contact the service provider's support and ask for solution from them by sharing the details in this thread with them.
From users' perspective, it would be beneficial to enforce the newer cryptography module version, to ensure that regardless of the local environment, this feature would be available. But that may be a product level decision.