NoCloud instance-id's never change

[Brent Baccala]

By default, the NoCloud datasource reports 'nocloud' as the instance-id.

While this can be changed in meta-data, the contents of the file are often static.

In particular, GNS3 appliances clone their disks from a master template.

The result is that all GNS3 virtual machines cloned from a single appliance get the same instance-id. In particular, the network doesn't get reconfigured correctly when a new instance boots.

I suggest adding the ability to obtain the system's UUID, as reported by dmi-decode -s system-uuid, in a Jinja template that can be used in meta-data, like this:

#cloud-config
instance-id: {{system-uuid}}

[Chad Smith (chad.smith)]

Thanks for filing this feature request and helping improve cloud-init.

I'll mark this bug as incomplete as we have a general discussion with your As you get a chance to respond and fill in details, please set the bug back to "New" status so we are alerted to re-review the conversation.

A couple of questions to start:
1. Is your NoCloud configuration seeded from the filesystem /var/lib/cloud/nocloud* or attached storage devices with a CIDATA label?
2. do you always know/expect that cloned GNS3 appliances need new network configuration?
3. do newly cloned appliances need to run any other cloud-init configuration such as host key setup, hostname config, storage resize or react to any optional custom user-data provided during clone launch? Or, is the configuration need across clone just limited to network reconfiguration?

I'm probably making assumptions that are incorrect, but I'll go with my gut. Feel free to fill in any misunderstanding here.

If your appliance clone process from disk templates is fairly aligned with typical golden image creation for VM launches, cloud-init would generally want to treat that golden appliance template as a clean base template where it has "not yet run".

Generally in for golden image creation we suggest the base template/image to be cloned runs the following before clone:
 sudo cloud-init clean --logs
 sudo rm /etc/machine-id # removing /etc/machine-id may not make sense on all distributions, but Ubuntu re-generates this id on boot if it doesn't exist
 sudo shutdown

The cloud-init clean should leave /var/lib/cloud/seed/nocloud*/ on the filesystem, but it will remove all semaphores which tell cloud-init that it has run on the system. Then any cloned appliance/image new boot will run through cloud-init configuration as if this were first boot of the image.

If this is not feasible in your environment, we can look to extend the NoCloud datasource to be a bit more dynamic as you request (and patches/participation are always welcome).

Honestly, I like this feature suggestion, but I think it is a little ways off to get you this type of feature (and any contributions are welcome to help us drive to supporting this feature). See "work breakdown" below.

The NoCloud datasource generally that metadata, vendor-data, network-config and user-data are "in place" and static at system boot time because there is no "cloud" backplane available to provide dynamic instance-data content.

The NoCloud datasource itself typically relies on the image/ISO/appliance/filesystem creator to update those static references when something changes that indicates config needs to be re-run.

If your appliance template creation mechanism doesn't have the ability to update the filesystem or image at the time of appliance clone or launch to seed a different instance-id for the cloned appliance, then we have a couple of options that I can think of:

1. One way around that would be using the NoCloud-net feature to use a URL accessible to your appliances which publishes (meta-data|vendor-data|user-data) so that you'd have control over cloned appliance boots getting new randomized instance-ids.

2. Another way around that is a boot servi...

[Brent Baccala (baccala)]

On Thu, May 19, 2022 at 3:21 PM Chad Smith <email address hidden>
wrote:

> Thanks for filing this feature request and helping improve cloud-init.
>
> I'll mark this bug as incomplete as we have a general discussion with
> your As you get a chance to respond and fill in details, please set the
> bug back to "New" status so we are alerted to re-review the
> conversation.
>
>
> A couple of questions to start:
> 1. Is your NoCloud configuration seeded from the filesystem
> /var/lib/cloud/nocloud* or attached storage devices with a CIDATA label?
>

When the appliance template is created, it seeds from a CIDATA virtual
CD-ROM. When a new instance of the appliance is created, there is no
additional attached storage device, so it picks up its configuration from
whatever was put in /var/lib/cloud/seed/nocloud

2. do you always know/expect that cloned GNS3 appliances need new network
> configuration?
>

yes

> 3. do newly cloned appliances need to run any other cloud-init
> configuration such as host key setup, hostname config, storage resize or
> react to any optional custom user-data provided during clone launch? Or, is
> the configuration need across clone just limited to network reconfiguration?
>

Not really. There's no easy way to provide additional configuration on a
per-instance basis, so right now the main thing is to ensure that the
network gets configured properly.

> I'm probably making assumptions that are incorrect, but I'll go with my
> gut. Feel free to fill in any misunderstanding here.
>
> If your appliance clone process from disk templates is fairly aligned
> with typical golden image creation for VM launches, cloud-init would
> generally want to treat that golden appliance template as a clean base
> template where it has "not yet run".
>
> Generally in for golden image creation we suggest the base template/image
> to be cloned runs the following before clone:
> sudo cloud-init clean --logs
> sudo rm /etc/machine-id # removing /etc/machine-id may not make sense
> on all distributions, but Ubuntu re-generates this id on boot if it doesn't
> exist
> sudo shutdown
>

I can do that. Right now I'm stopping cloud-init completely at that point
by touching /etc/cloud/cloud-init.disabled, replacing the file in
/etc/netplan with my own netplan config file, and shutting down the VM to
clone the disk.

Your suggestion makes sense and is good to know. I didn't realize this was
the recommended procedure. I had figured that the design was for
cloud-init to treat a newly cloned virtual machine as an instance change
without having to do these steps.

> If your appliance template creation mechanism doesn't have the ability
> to update the filesystem or image at the time of appliance clone or
> launch to seed a different instance-id for the cloned appliance, then we
> have a couple of options that I can think of:
>
>
> 1. One way around that would be using the NoCloud-net feature to use a
> URL accessible to your appliances which publishes
> (meta-data|vendor-data|user-data) so that you'd have control over cloned
> appliance boots getting new randomized instance-ids.
>

GNS3 provides no instance-facing API. It's primarily a tool ...

[Launchpad Janitor (janitor)]

[Expired for cloud-init because there has been no activity for 60 days.]

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3977