feat: migrate nutanix linux to HCL

[fad3t]

Change description

Migrate the Nutanix Linux Packer JSON template into HCL.

Additional context

Following changes have been applied:

• new HCL files replacing the packer.json.tmpl file -- using the standard Packer folder structure (variables, locals, ..)
• the HCL variables have been defined in the Nutanix folder for now, even if they're shared across providers. JSON vars don't need to be declared upfront, so other providers don't require this for now. Once all providers have been migrated to HCL, we should be able to simplify this part.
• the old packer.json.tmpl file has been removed
• the .tmpl is no longer needed as the bash script writes the password into a pkrvars file directly
• I kept Windows out of scope for now. I'd personally make a dedicated windows/ directory containing all the Windows-related HCL files to avoid naming conflicts with Linux variables, but I kept it for later so people can share their opinion/feedback on this.
• The flatcar build name has been simplified, as the channel and version variables seem unused in the Nutanix context. Please correct me if I'm wrong.

Misc:

• I tested a build on a Nutanix setup, image was successfully built.
• Some code has been AI-generated, mostly the repetitive copy-paste and vars descriptions.
• Idea would be to continue the migration effort, however I can only test a few providers.. Let me know if you'd like to contribute.

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign mboersma for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubernetes-prow]

Hi @fad3t. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[mboersma]

/ok-to-test

[tuxtof]

LGTM

@mboersma are we OK to start migrating templates to HCL, is it a request for the other providers too ?

[mboersma]

are we OK to start migrating templates to HCL?

@tuxtof I don't see why not, it's what Packer has recommended for a while. I don't know that we need to convert everything, but I think it's fine to work in that direction.

[mboersma]

Thanks for working on this migration! I noticed two compatibility issues: the Linux build and validation commands no longer load packer/nutanix/nutanix.json, even though that’s the documented configuration path, and nutanix_port / nutanix_insecure no longer honor NUTANIX_PORT / NUTANIX_INSECURE. Could we preserve both behaviors so existing Nutanix build workflows continue to work?

[tuxtof]

are we OK to start migrating templates to HCL?

@tuxtof I don't see why not, it's what Packer has recommended for a while. I don't know that we need to convert everything, but I think it's fine to work in that direction.

perfect so in this case , let's pursue 👍🏻

[fad3t]

Thanks for working on this migration! I noticed two compatibility issues: the Linux build and validation commands no longer load packer/nutanix/nutanix.json, even though that’s the documented configuration path, and nutanix_port / nutanix_insecure no longer honor NUTANIX_PORT / NUTANIX_INSECURE. Could we preserve both behaviors so existing Nutanix build workflows continue to work?

Thanks for the review!

For the packer/nutanix/nutanix.json you're right, I removed it because it was empty (thought it was a leftover) -- and I didn't know the documentation was explicitly telling users to set their Nutanix config/creds into this file (I'm personally building my own file that I pass to Packer).

Regarding NUTANIX_PORT and NUTANIX_INSECURE that depends. The migration script initially defined those 2 variables as string, using the environment variable as defaults. However, the Nutanix Packer provider expects number and bool respectively, so I preferred aligning with the expected type, which means we can't read the environment vars anymore..
That's a choice we'll have to make; either we preserve the current behavior and let Packer automatically convert the string into the target type (which it does very well as long as the input is clean) - or we take the opportunity to set the correct variable type (which I personally prefer). I also believe those 2 vars are not often overridden -- or at least the port number. Let me know what you prefer and I'll adapt :)

[mboersma]

@fad3t let’s preserve compatibility while keeping the variables strictly typed. Could you fall back to converting NUTANIX_PORT and NUTANIX_INSECURE when the typed variables are unset, with explicit var-file/-var/PKR_VAR_* values taking precedence?

Please also restore nutanix.json for the Linux build and validation paths. We can document the PKR_VAR_* names as preferred going forward.

[fad3t]

@fad3t let’s preserve compatibility while keeping the variables strictly typed. Could you fall back to converting NUTANIX_PORT and NUTANIX_INSECURE when the typed variables are unset, with explicit var-file/-var/PKR_VAR_* values taking precedence?

Please also restore nutanix.json for the Linux build and validation paths. We can document the PKR_VAR_* names as preferred going forward.

To be sure I fully understood what you mean, you'd like to have something in between (a local) that'd use the typed variable if it is set, and fall back to the string variable (sourced from the env) otherwise?

[fad3t]

I've updated as per @mboersma feedback - let me know if anything's missing!