Tom Parrott

If not then I think one way we can fix this is to require `--restricted` be passed when providing `--projects` flag.

Hi @holmanb I'm afraid im not really following what it is that LXD needs to change here? Also, not sure if relevant, but using the `user.*` prefix is deprecated for...

> I'm happy to submit a PR for this, but we need to release a change in cloud-init first to accommodate this expectation. This is why I filed a bug...

> The relevant key is `user.meta-data`, which wasn't actually deprecated (despite being used for exposing information to cloud-init just like the others): Hrm, that is curious, I wasn't expecting that,...

> This isn't necessary because meta-data isn't part of cloud-config. Please could you explain this statement. I'm confused why a key being used by cloud-init isn't part of cloud-config?

> In order to preserve the current behavior while creating a path to using standard-compliant yaml while preserving backwards compatibility, we could do the following: > > 1. cloud-init could...

@holmanb Hi, would you mind booking a meeting to discuss this issue? Thanks

Thanks for the call @holmanb As discussed, you can change the instance-id exposed to cloud-init via LXD's devlxd metadata API (https://documentation.ubuntu.com/lxd/en/latest/dev-lxd/#meta-data) by changing ` volatile.cloud-init.instance-id` see: https://documentation.ubuntu.com/lxd/en/latest/reference/instance_options/#instance-volatile:volatile.cloud_init.instance-id To change `local-hostname`...

what form would `volatile.cloud_init.public-keys` take?

> > > No need to support two format types for this content if it adds unnecessary complexity to lxd for a `volatile.cloud-init.public-keys` setting. [cloud-init public-key processing currently supports strings,...