Add templating support for cloud-init in lima.yaml

[jandubois]

To avoid inflating the numbers of the limayaml fields, can we consider to support templating cloud-init yaml in limayaml?

Originally posted by @AkihiroSuda in #2119 (comment)

I think we should consider it, but it may take a bit of an effort. Here is what I think is needed (just brainstorming; please correct if I'm missing something):

• Import the cloud-init json schema
• Do whatever is necessary to make sure it is OpenAPI compliant (if it isn't already)
• Turn it into a Go package using swagger
• Add cloudInit field to lima.yaml
• Create additional validations for potential conflicts with settings managed by Lima
• Modify cidata to merge our settings into the cloud-init data structure; we can no longer use Go templating, but need to encode the structs to YAML.
• Update lima-init in alpine-lima to deal with potential formatting changes

If this works, then we should decide how we import the JSON schema into the lima repo, how we update it etc. I think it would be best to have a separate repo for this, that maybe uses git submodules to include upstream cloud-init, and then checks in the swagger output as a Go module. That way we don't need to require swagger for building Lima.

[AkihiroSuda]

Import the cloud-init json schema

Can we just use map[string]interface{} ?

[jandubois]

Can we just use map[string]interface{} ?

We could, although it makes updating fields a bit awkward when we are merging in the fields that Lima needs to control. Maybe we can use something like https://github.com/Jeffail/gabs?

Also, I haven't checked if encoding the data again as YAML will write out the fields with lowercase names. I guess it needs to, if it supports proper round-tripping.

But how do we validate the user-data part if we don't use the schema? Hope that the VM will still somehow boots up, and let people look at /var/log/cloud-init-output.log?