fix: re-add variant support for templates

[dankm]

Restore the previous support for specifying the variant used in
template rendering instead of always depending on the host.
Before #5027 this was configured with the --distro option to setup.py,
so use the distro meson option.

Proposed Commit Message

fix: re-add variant support for templates

Restore the previous support for specifying the variant used in template rendering instead of always depending on the host. Before #5027 this was configured with the --distro option to setup.py, so use the distro meson option.

Fixes GH-5027

Additional Context

Test Steps

Merge type

• Squash merge using "Proposed Commit Message"
• Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

[holmanb]

Thanks @dankm. Please sign the CLA when you get a chance.

Also, why is this needed? Does detection not work for some distro?

[dankm]

Thanks @dankm. Please sign the CLA when you get a chance.

I did earlier, but after I submitted this pull request. I had previously signed, but seems the terms were updated.

Also, why is this needed? Does detection not work for some distro?

Detection works everywhere I've tried. My use case is cross-compiling. In particular in OpenEmbedded. We want the cloud-init it builds to reflect the target system, not whatever host system happens to be doing the building. Without this change I get different output on a Ubuntu host and a Fedora host, despite my target system being neither.

[holmanb]

Thanks for this proposal @dankm. One comment, plus there is a merge conflict.

@blackboxsw Supporting two ways to accomplish the same thing is a smell. If we're going to support cross-compiling, then detection logic isn't a source of truth that we can reliably trust - and it is logic that we would have to maintain in upstream indefinitely for N distros. In other words, it is low value and bears a cost. The meson build tooling is still new and will have to be adopted by every distro eventually (I doubt many, if any, have). I suggest that instead of using "detection with overrides", we could just require it to always be set. This would give us a single source of truth we can always trust. Anybody that has already added meson support will have to add the extra argument, but I doubt there are many of those and the change is not significant. For everyone else it will just be part of the transition. Thoughts?

[holmanb]

Since this is only required for building packages on different distros, it would be good to document why this option even exists when "auto" is the default.

[github-actions]

Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close.

If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging blackboxsw, and he will ensure that someone takes a look soon.

(If the pull request is closed and you would like to continue working on it, please do tag blackboxsw to reopen it.)