Migrate Packer files from JSON to HCL

[johananl]

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

[codenrhoden]

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.

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[johananl]

/remove-lifecycle stale

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[johananl]

/remove-lifecycle stale

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[rymancl]

/remove-lifecycle stale