It would be good to be able to create a cloud-init script per application. At the moment the only way to use cloud-init is per model.
The idea here is to be able to do custom configuration (fine granularity) of a machine based on the application. The example I have and which I deployed is configuring static ip addresses for juju lxd machines. I know this is not yet supported but I was able to do it through cloud-init and lxd profiles. I also did that because Link local subnets are not supported by Juju. The assignation of ip addresses on specific interfaces is based on the application (Example, I’m not able to do the same logic for prefix assignation for ceph-osd application and ceph-mon application). It would be good to have a cloud-init based on the application in this situation. Here is a cloud-init example that I used for this deployment:
Just for background, the reason this is per model is that you can place units for more than 1 application to any given machine. The default is to provision a new machine/container, but the user can use the --to placement option to reuse a machine already provisioned. And you can also juju add-machine to create an empty machine and use that later, so any app specific cloud init script would not work there either.
If we were to implement this, we would have to disallow placement (–to) for charms which have their own cloud init scripts; any such charms could only have units deployed to a new machine/container.
Hello. It would be really useful to do such an implementation - because we can have machines grouped by tags (e.g. in MAAS or in K8S) which are applied specific cloud-init scripts , for example group of specially prepared Ubuntu Hosts with specific modprobe parameters with specific hardware and so on.
For this, Juju has the network spaces concept I believe. It allows binding of services to specific named subnets for which the machine may have access to.
It does not offer 100% control over network specifics, but surely a degree.
I have not yet explored the specifics myself here, but I would love to explore it better at some point.
