User configurable cloud-init

Headline:
Make it possible to add extra cloud-init lines to the lines Morpheus already uses


Description:
In running cloud-init there is a great way of adjusting the OS image to the deployment of the VM it becomes.
Currently Morpheus allows to adjust “user-data” a.k.a. runcmds: from the cloud-init setup.
We propose to have all the cloud-init fields to have adjustable config (or added config).
Why?

  • when trying to only have static IP addresses in Linux every Linux distro has it’s own ways and Morpheus doesn’t currently (5.5.3/6.0.5) allow to adjust the “files” part of your cloud-init in which with the powerfull Morpheus templates you could craft all the necessary adjustments.
  • allowing to add lines to the “files” part could make life easier in setups which need to be there in different parts of clouds without the need to have different images for the same virtualization but different clouds (for instance your DNF/YUM/APT repositories)
  • allowing to adjust the cloud-init on other parts allows to adjust partitions, LVMs (all parts of which make cloud-init great

Example/Use case(s):
As an example an working cloud-init for static IP assignment and correct config of DNF repositories for an RHEL based image, which circumvents the need for DHCP in a Linux image to get the static IP assignment from Morpheus

#cloud-config
# 1vCPU, 4 cores, 12 GB vMEM, 120GB disk, VLAN xxx
fqdn: xxx.xxx.nl
ssh_pwauth: true
chpasswd: false

users:
  - name: ansible
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    lock-passwd: false
    groups: wheel, users
    passwd: $6$.....
write_files:
  - path: /etc/sysconfig/network-scripts/ifcfg-eth0
    content: |
      # Static IP Configured
      DEVICE=eth0
      TYPE=Ethernet
      BOOTPROTO=static
      STARTMODE=auto
      IPADDR=a.b.c.d
      NETMASK=255.255.255.0
      GATEWAY=a.b.c.1
      ONBOOT=yes
      DOMAIN=xxx.nl
      DNS1=a.b.c.x
  - path: /etc/sysconfig/network
    content: |
      NETWORKING=yes
      NETWORKING_IPV6=no
      #IPv6 Must be enabled soon
  - path: /etc/yum.repos.d/appstream.repo
    content: |
      [Appstream]
      baseurl=http://a.b.c.y/repos/RedHat/8/rhel-8-for-x86_64-appstream-rpms
      enabled=true
      gpgcheck=false
      name=Red Hat Enterprise Linux 8.7.0 Appstream
      metadata_expire=-1
  - path: /etc/yum.repos.d/baseos.repo
    content: |
      [BaseOS]
      baseurl=http://a.b.c.y/repos/RedHat/8/rhel-8-for-x86_64-baseos-rpms
      enabled=true
      gpgcheck=false
      name=Red Hat Enterprise Linux 8.7.0 BaseOS
      metadata_expire=-1
runcmd:
  - rm -rf /etc/ssh/ssh_host_* /etc/machine-id
  - systemd-machine-id-setup
  - systemctl restart NetworkManager
  - /usr/libexec/openssh/sshd-keygen rsa
  - /usr/libexec/openssh/sshd-keygen ecdsa
  - /usr/libexec/openssh/sshd-keygen ed25519
  - systemctl restart sshd
  - touch /etc/cloud/cloud-init.disabled
  - sudo reboot

5 Likes

So this is already supported in the virtual image edit level however one should NEVER be setting up address info in a cloud init user data. This is handled by cloud init via metadata and network data not user data. It is configured based on your selected network and pool and passed down.

Hi David,

Thanks for your response, we are running into issues with only being allowed to edit user-data which reflects to only runcmd: part of the cloud-init possibilities. This is for us not broad enough.
As for the example above, when the cloud-init data as a whole could be put to work in the templates of Moprheus, we could just fill every field with variables Morpheus already knows.
For instance, when you don’t have a DHCP server available, Morpheus still boots the image in DHCP mode and at the end waits to runcmd: with a curl to the Morpheus server to get the fixed IP. This will run into a stalled system/catch 11.
This request is a lot broader than the above sample and should opt to have most features (I understand some will be blocking) from Module reference - cloud-init 23.2.1 documentation.
With the restrictive clouds we use we do not have all options you have in an open cloud.

The options you mentioned from network and pool passing down weren’t mentioned as a solution to my issue.

Edward