deploy_vms: add cloud-init support for VM provisioning - #953
Conversation
b5ff2e4 to
2366c07
Compare
2366c07 to
057275a
Compare
insatomcat
left a comment
There was a problem hiding this comment.
I don't really have the need for this feature, but I'd say "why not" if it's interesting to the community.
What do you think @dupremathieu
It can be useful for provisioning Ubuntu VM. |
057275a to
46596d8
Compare
|
I think we should document this feature somewhere in the Wiki. @eroussy what is the best pages for that? |
I would advise writing a new a subpage of this one : https://lf-energy.atlassian.net/wiki/spaces/SEAP/pages/534347789/Virtual+machines+deployment |
https://lf-energy.atlassian.net/wiki/spaces/SEAP/pages/1163329602/Cloud-init+VM+provisioning |
| # guest inner OS on first boot through a NoCloud seed disk. Requires the base | ||
| # image to ship cloud-init, and `cloud-localds` (package cloud-image-utils) on | ||
| # the Ansible controller. Remove this block to deploy without cloud-init. | ||
| cloud_init: |
There was a problem hiding this comment.
I do not like putting this directly in the VM example inventory.
This inventory should be the a simple inventory to kick start VM deployement
Then the rest of the documentation should be in the ansible roles README
Please remove this part
There was a problem hiding this comment.
Done : I removed the cloud_init block from the example inventory; the documentation and an example now live in the cloud_init_seed role README.
9fc694e to
ae79e25
Compare
ae79e25 to
ea9b9d9
Compare
|
@dupremathieu, @eroussy & @insatomcat is everything ok? |
Add an optional `cloud_init` mapping per VM to configure the guest inner OS on first boot through a cloud-init NoCloud seed disk. A new `cloud_init_seed` role builds the seed image (meta-data, user-data and optional network-config) on the Ansible controller with cloud-localds. The deploy roles then attach it to the VM: - cluster: passed as an additional_disk imported by vm-manager; - standalone: copied to the disk pool and attached as a vdz disk. Every key of the `cloud_init` mapping is rendered as-is into the #cloud-config user-data, except the reserved keys hostname, instance_id, network and user_data_file. The feature is opt-in per VM: VMs without a `cloud_init` key keep the previous behaviour. cloud-localds comes from cloud-image-utils, added to the cqfd container image so the controller environment has the tool. Squashed from #953. Signed-off-by: Gabin-CC <gabin.laurent@rte-international.com> Signed-off-by: Florent Carli <fcarli@gmail.com>
Add an optional `cloud_init` mapping per VM to configure the guest inner OS on first boot through a cloud-init NoCloud seed disk. A new `cloud_init_seed` role builds the seed image (meta-data, user-data and optional network-config) on the Ansible controller with cloud-localds. The deploy roles then attach it to the VM: - cluster: passed as an additional_disk imported by vm-manager; - standalone: copied to the disk pool and attached as a vdz disk. Every key of the `cloud_init` mapping is rendered as-is into the #cloud-config user-data, except the reserved keys hostname, instance_id, network and user_data_file. The feature is opt-in per VM: VMs without a `cloud_init` key keep the previous behaviour. cloud-localds comes from cloud-image-utils, added to the cqfd container image so the controller environment has the tool. Squashed from #953. Signed-off-by: Gabin-CC <gabin.laurent@rte-international.com> Signed-off-by: Florent Carli <fcarli@gmail.com>
c5a5cfc to
cea647d
Compare
Hi Gabin |
Add an optional `cloud_init` mapping per VM to configure the guest inner OS on first boot through a cloud-init NoCloud seed disk. A new `cloud_init_seed` role builds the seed image (meta-data, user-data and optional network-config) on the Ansible controller with cloud-localds. The deploy roles then attach it to the VM: - cluster: passed as an additional_disk imported by vm-manager; - standalone: copied to the disk pool and attached as a vdz disk. Every key of the `cloud_init` mapping is rendered as-is into the #cloud-config user-data, except the reserved keys hostname, instance_id, network and user_data_file. The feature is opt-in per VM: VMs without a `cloud_init` key keep the previous behaviour. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Gabin-CC <gabin.laurent@rte-international.com>
The deploy_vms roles build the cloud-init NoCloud seed on the Ansible controller with cloud-localds (provided by cloud-image-utils). Add it to the cqfd container image so the controller environment has the tool. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Gabin-CC <gabin.laurent@rte-international.com>
cea647d to
f33cfb0
Compare
"Looks ok to me. I'll merge that when the stack of PR/CI is free"
Summary
Adds optional cloud-init provisioning to VM deployment. Today SEAPATH only deploys and runs VMs ("does not handle any virtual machine inner configuration"); this lets a VM be configured on first boot (hostname, users, SSH keys, static network, packages,
runcmd, the nativeansible/ansible-pullmodule, ...) straight from the inventory.Companion change in
seapath/build_debian_isoships cloud-init in the VM image andcloud-localdson the hypervisor image: link to the build_debian_iso PRHow it works
Uses the cloud-init NoCloud datasource. For each VM that defines a
cloud_initmapping, a newcloud_init_seedrole builds a small seed image (filesystem labelledcidata, holdingmeta-data/user-data/network-config) on the hypervisor withcloud-localds. The deploy roles then attach it to the VM:cluster_vmviaadditional_disks(imported by vm-manager, no vm-manager change required);vdzdisk inguest.xml.j2.cloud-init in the guest discovers the disk by its
CIDATAlabel and applies the config on first boot.Inventory interface
Add a
cloud_initmapping to a VM to enable it. Every key is rendered as-is into the#cloud-configuser-data, except the reserved keys:hostnamemeta-datalocal-hostnameinstance_idmeta-datainstance-id (defaults to the VM name)networkversion: 2header is added)user_data_fileSo the full cloud-config schema (
users,packages,runcmd,write_files,ansible, ...) is available without per-field plumbing. See the newcloud_init_seedrole README and the extendedinventories/examples/seapath-vm-deployement.yaml.Backwards compatibility
Opt-in per VM: a VM without a
cloud_initblock keeps the exact previous behaviour (no seed built, no extra disk).Requirements
cloud-localds(cloud-image-utils) on the hypervisor — shipped by SEAPATH host images from the companion PR.Testing
Deploy a VM with a
cloud_initblock and verify inside the guest:cloud-init status --long→done, hostname / users / network applied.