On 11/12/2024 14:42, Jeremy Stanley wrote:
On 2024-12-11 11:32:36 +0000 (+0000), Sean Mooney wrote: [...]
note that we also have a write once mechanic where by a first boot agent can generate an admin password withing the guest and post that back to the metadta api to save it to the nova db. [...]
Tangential, sorry, but could this sort of mechanism also be used to provide an out-of-band verification of SSH hostkeys generated on first boot for *nix type guests? We used to splat them to the primary terminal and then try to scrape them from the console log, but having a structured API response would be a lot cleaner (or did something similar already get added and I missed it?).
so this "feature" is more or less undocumented and i believe it was originally added because AWS ec2 before we started to use specs for things like this. its something we rediscover is a thing every few years when we do a code audit. so in that sense the current code is kind of a special snowflake and not directly usable for your use case. its basically this elfi block https://github.com/openstack/nova/blob/f729a7fb133b1cda467ac6be2a05775769bff... which no other metadata path supports. it was added by https://github.com/openstack/nova/commit/a2101c4e7017715af0a29675b89e14ee288... in grizzly With that said i see the merrit in supprot some kind of reporting for limited trusted boot type use cases such as providing the ssh host key fingerprint so you can validate that the vm is the one you expect it to be. im not sure how i would feel about allowing arbiarty metadata to be store this way. is there something beyond the host key that would be useful for you to record on boot? perhaps we can try and capture this is a spec or separate thread and work out what an mvp would look like. there would basically be two part, one extednign the metadata api to support recording the host key fingerprint somewhere, and then making that discoverable via the main api perhaps in server show. is we allowed read write access to all instance metadata we would would not actually need to modify the main api as you can already list metadata on an instance but im worried that could be abused so i don't know if that is a good idea. the nova metadata api is not intended a a high performance key value store so i dont necessarily think it would be a good idea to extned this to a generic crud api but we certainly could provide limited support for targeted uscease liek the one you raise.