Proper way to handle XO CloudConfigDrive and CloudInit post provisioning

dkmuir

Maybe it's a non-issue, but I was wondering what is the right way for dealing with the XO CloudConfigDrive after a VM has been provisioned? Do I just leave it there, or should it be removed from the VM?

The other question I have relates to the cloud-init service. Should that be disabled after booting up?

So for example, should something like the following config be used with a stock ubuntu cloud image from https://cloud-images.ubuntu.com ?:

#cloud-config
hostname: {name}%
users:
  - default
ssh_authorized_keys:
  - ssh-rsa ...
package_update: true
package_upgrade: true
packages:
  - xe-guest-utilities
byobu_by_default: system
runcmd:
 - systemctl disable cloud-init
power_state:
  delay: "+30"
  mode: poweroff
  message: Bye Bye
  timeout: 30
  condition: True

And then remove the cloud config drive and then start the VM again, or can the disk be safely removed while the machine is running?

olivierlambert

@fohdeesha will confirm but I think it's only loaded on boot, so I don't see any issue to remove it afterward

dkmuir

@olivierlambert Thanks!

fohdeesha

@dkmuir when cloud-init is installed on a VM, it runs every single boot and searches for a config drive, mounts it, reads it, then unmounts it. If it sees it's the same as a previous config that's already been loaded (which is what will happen on a deployed VM after the firstboot), it'll ignore it and not do anything - it won't re-apply the same old config. So you can safely leave the old config drive there, however you can also safely remove the drive entirely as well - cloud-init will still scan on startup, but it won't find a config drive to even check. You can remove the config drive while the VM is running without issue, it's not even mounted any longer (cloud-init only temporarily mounts it during boot)

You can also remove cloud-init iself indeed after the first boot

dkmuir

@fohdeesha Thanks for the thorough explanation. Took me a while to get the network configuration working, but I think I've got it all working nicely now from a stock Ubuntu cloud image.

For those interested:

My cloud init:

#cloud-config
hostname: {name}
users:
  - default
ssh_import_id:
  - gh:<username>
package_update: true
package_upgrade: true
packages:
  - xe-guest-utilities
byobu_by_default: system
runcmd:
 - systemctl disable cloud-init
power_state:
  delay: "+1"
  mode: reboot
  message: Rebooting system
  timeout: 5
  condition: True

My network config:

version: 2
ethernets:
  eth0:
    addresses: []
    dhcp-identifier: mac
    dhcp4: true
    nameservers:
      search:
        - my.nameserver.local

furyflash777

If delete CloudConfigDrive, then it will try to search configuration disk every time and break network config.
You can just remove drive and create empty file /etc/cloud/cloud-init.disabled
It will disable cloud-init.

olivierlambert

Are you sure about that? On which distro with which config? I have no issue when I remove it on Debian here

fohdeesha

@furyflash777 I'm assuming you're on Ubuntu? Indeed as Olivier said this is tested on Debian and doesn't cause issues, but it seems on the newer Ubuntu versions with cloud-init, the new Netplan based network manager and how it interacts with cloud-init breaks/gets wiped if no cloud-init drive is found. Yet another cloud-init bug to track down