On 14/10/2025 14:50, Jeremy Stanley wrote:
On 2025-10-14 09:10:19 +0100 (+0100), Sean Mooney wrote: [...]
long term i would like to remove the keypair api form nova entirly and add it to keystone.
in my dream world keystone user would have keypair registered and you woudl be able to use an ssh key to auth to keystone to get a token.
nova would also supprot using the same keyapir form keyston to inject into the instance as we do today via cloud init but it would not be stored in nova anymore. [...]
And also ideally rename it. The term "keypair" was accurate when Nova was generating both halves of the key, but what the API (and documentation) calls a keypair now is really just a public key digest used to verify that the user has possession of the corresponding private key. OpenSSH keeps them in a file called "authorized_keys" so something like "sshauthkey" might make sense.</bikeshed>
we do actully use it for one other usecase. we use it to encrypt the admin password of a server and return it to the client if you have cloud init or similar generate it but again we are just use the public key for its intended usecase, to encypte data that only the private key can decrypted. so we coudl definlty call it publickey or simialr althoguh it can be an x509 certificat as well for windows guest and winrm ectra so ya if we were to do this properly in keystone in teh future we shoudl choose a more accurate name i agree. that also make the upgrade path on the nova side simple ebcause you do not need to disambiguate where the key is sotred. if tis keypair its still in nova if its <new name> you pass a refence to it in keystone or where ever it lives.