We at Atix are using image based provisioning with cloud-init to provision the Proxmox host which involves attaching cloud-init config files (user-data, meta-data, network-config) as an iso image to the VM while booting the VM. Since foreman only offers user-data kind template, therefore, in order to provide config files we are currently providing all three config files in one user-data kind template and configuring OS with it. This template is then converted to iso image on Proxmox server and attached to host, see, Add Cloudinit support using iso image by Manisha15 · Pull Request #294 · theforeman/foreman_fog_proxmox · GitHub.
There are two options to provide these three config files as templates in foreman:
Continue to use user-data kind provisioning template and provide user-data and network-config in one template
Extend foreman to offer option to set three different provisioning templates in Operating system to configure user-data, network-config and optionally meta-data.
We want to extend it to other Compute resources as well. Which option would be feasible and user-friendly?
And any other solutions are also welcomed.
I think it will not hurt to have more options as already other cloud-init options try to get more than user-data.
But to be user-friendly good templates to start with are needed (something we typically have) and we need to simplify how the templates are associated to the operating system (I think this is only solved for EL and Fedora so far and I read to many posts here where someone mixed things up especially since Ubuntu’s Autoinstall made it even worse).
From my perspective, Ubuntu’s Autoinstall should be of kind “Provision template”, but this might conflict (at least for now) with accessing these templates via Ubuntu’s installer over HTTP/HTTPS and how Foreman handles this template kind. Anyway, slightly other discussion.
I vote for option 2.
I like the idea to deduce the content from the name, especially with the defacto standard Cloud-init nowadays . “User data template” actually should contain Cloud-Init’s user-data. And the same for network configuration (network-config). Having this separated and adapted by all compute resources would be awesome and would work for all hypervisor and cloud providers (latter probably only user-data).
With an adapted VMware compute resource plugin we could also get rid of this “Cloud-init template” kind and the corresponding select box in the OS configuration.
Ping @lzap: this is the topic I was talking about on Tuesday.
We would be quite happy to hear your guys opinion on this topic, discuss it and collect as much as possible requirements and input. Just want to make sure that we are on the same page before we start working on this.
I do not have a strong opinion on this one as cloud-init in Foreman is not something that our customers use on daily basis. I see no reason why Foreman should not be extended further.
Foreman carries two different kinds: “User data” and “Cloud init” and both are used for different purposes. One for injecting user data into cloud instances (or VMs) and other is what is I believe called “Nocloud Cloud-Init endpoint”. They usually both carry the same payload (cloud-init) but the way it works is very different (injection vs HTTP rendering). This is very confusing and we might consider renaming one, or the other.
So I would love seeing us to solving the problem in a transparent way. Have you thought about fully native cloud-init ISO generation API that would be available to all compute resources? I am thinking ability to associate one or more templates to a VM, not to an operating system.
