image-builder
image-builder copied to clipboard
Migrate Packer files from JSON to HCL
Is your feature request related to a problem? Please describe.
JSON doesn't support comments whereas HCL does. Being unable to comment inline makes it harder to maintain Packer code because we can't explain tricky/unusual bits, add TODOs in context etc.
Describe the solution you'd like
As of 1.7.0, the recommended config format for Packer is HCL. We should consider migrating. There is an upgrade tool.
Describe alternatives you've considered
We could stay with JSON and not use comments.
Additional context None.
/kind feature
Thanks for starting this conversation, @johananl. It's definitely worth discussion, especially since the recommendation changed with Packer 1.7 as you pointed out. I know the project had talked about it once before (well over a year ago), but I can't find any notes that were captured on the topic. One thing that's nice about the JSON files is that they are easily manipulated with tools like jq, but we've talked about making some pretty sweeping changes in this area anyways, and HCL may as well be a part of that discussion.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Hi,
Can we revamp the discussion? I'm interested in working on this since this can be a blocker for #1437 - JSON template are very limited as also indicated in the official packer documentation. Are you okay with this?
doing a big change like this probably depends on the outcome of what we end up doing with https://github.com/kubernetes-sigs/image-builder/issues/1246. Maybe its time to re-discuss the usage of packer
Why is this a blocker for #1437?
Hello! Sorry, I closed #1437 and re-open as #1442 - I mishandled the commits and did all the work on the main branch, causing issues. Regarding why is this a blocker: in #1442 I'm proposing to deprecate containerd_version user variable by introducing a standard cri_version. To implement this I would like to start gradually implementing the new variable, but maintaining the older one with more importance. JSON packer file does not allow complex evaluation as HCL2 does.
To be more clear I would like to leverage HCL2 more complex function to keep the user un-aware of the change, without the needs to keep complex handling into the ansible files.