[Feature] Add '-force' support for templates

[sbrupert]

Hello! Hope everyone's having a pleasant start to the week :)

Change Summary

This PR adds logic to template handling based on the usage of Packer's -force flag.

If the force flag is used, the builder will replace/delete any templates with the same name as the current builds "vm_name" parameter.

If the force flag is not used, a new template will be created every time the builder is run.

Why These Changes?

I'm slowly migrating to XCP-NG in my HomeLab, and part of that process is checking out the support for the various IaC tools I'm used to with vSphere (Packer, Terraform, Ansible, etc).

I use Packer with vSphere to create "rolling" templates for the various OS's I use. This reduces the amount of time it takes to setup a VM cloned from the template, since it's always got the latest updates and patches.

I found that this XCP-NG builder works a bit differently than I and other users of the vSphere ISO builder are used to when it comes to managing existing templates.

vSphere does not allow templates with duplicate names using Packer, in which case you are required to use the -force flag to permit the builder to remove the old template before creating the new one. This behavior allows one to create "rolling" or "golden image" templates as I and other's are used to (PR #75)

Since XCP-NG does allow you to have multiple templates with the same name, I wanted my changes to allow for both workflows:

1. Creating single, "rolling" golden image templates.
2. Create multiple, image templates differentiated by a build date tag, name, etc.

I believe implementing this logic by utilizing the -force flag is appropriate since it's simple (already implemented by packer upstream, don't have to add new variables/parameters, users are already familiar with the flag's purpose/logic). Additionally, this implementation adheres to Packer's own documentation regarding the purpose and usage of the -force flag:

Forces a builder to run when artifacts from a previous build prevent a build from running. The exact behavior of a forced build is left to the builder. In general, a builder supporting the forced build will remove the artifacts from the previous build. This will allow the user to repeat a build without having to manually clean these artifacts beforehand.
- Packer Commands Docs

Callouts

1. This PR only implements logic regarding the -force flag for templates. The XVA image creation logic was not touched. This is technically an inconsistency with the force flag logic since the XVA images seem to use their own logic for handling artifact creation (format, skip_set_template)

2. I am not a programmer by trade (DevOps/Sysadmin here 👋🏻) and most of my amateur experience is in Python. I thought this was a great excuse to learn some Golang and finally make my first contribution to an open source project 😄

With that being said, comments, questions, and concerns are absolutely welcome!

Cheers!

[nathanael-h]

Hello Steven,

Thank a lot for the PR. It comes with a very good explanation, which helped me a lot to understand your context, need and goal. I agree that having a way to continuously rebuild golden image template is a nice to have. I think it would benefit not only homelabers (like you and I) but also our customers with bigger infra, teams and needs.

I went through the code, and it looks good to me. How much did you test this PR since you sent it a few months ago?

@AtaxyaNetwork could you take a look a this PR ?

[AtaxyaNetwork]

I just read the code, didn't have time to test it yet.
A few points I want to raise:

• I would like the step_cleanup_template.go and step_get_template.go to be in the same file. For example handle_template. IMO we already have to many file on the common folder
• step_type_boot_command.go changes seems like a breaking change. Ideally we need backward compatibility
• The deletion of the "old template" seems at the right place. We don't want to delete template until we are sure the build is ok.

I need to compile and test some build before giving a go. But I like this feature, it can be very useful, especially for CI !

[sbrupert]

Hello Nathanael,

Thank you for the kind words! I have not tested my changes on top of latest from the project. I'm going to rebase my work with the latest changes and re-test to confirm that everything still works as intended.

@AtaxyaNetwork, Thank you for the feedback! I'll convert this PR to a draft while I get those implemented!

[nathanael-h]

Super @sbrupert thanks for the rebase, and your coming tests, I'm looking forward to read the results!

[sbrupert]

Thanks @nathanael-h!

Ok so I've rebased and made some changes based on the feedback received from @AtaxyaNetwork:

• I would like the step_cleanup_template.go and step_get_template.go to be in the same file. For example handle_template. IMO we already have to many file on the common folder

Both files have now been consolidated into step_manage_template.go.

• step_type_boot_command.go changes seems like a breaking change. Ideally we need backward compatibility

The code has been updated to prefer looking up the VM by UUID. If the UUID is unavailable or the lookup fails, we proceed with the traditional method of looking up by name.

---

I was able to confirm the -force behavior works as intended with these changes and the rebase!

Without the -force flag, existing templates are left alone and a new template is created.

==> xenserver-iso.ubuntu-2404: Successfully shut down VM
==> xenserver-iso.ubuntu-2404: Step: Cleaning up templates
==> xenserver-iso.ubuntu-2404: Ignoring 1 templates since -force was NOT specified!
==> xenserver-iso.ubuntu-2404: Successfully set VM as a template

With -force enabled, any existing templates matching the build name are removed after a successful build.

==> xenserver-iso.ubuntu-2404: Successfully shut down VM
==> xenserver-iso.ubuntu-2404: Step: Cleaning up templates
==> xenserver-iso.ubuntu-2404: Deleting 2 templates since -force was specified!
==> xenserver-iso.ubuntu-2404: Successfully set VM as a template

---

Please let me know if you guys have any questions or would like any adjustments, I'm happy to iterate.

Thanks again for the review and feedback!

[AtaxyaNetwork]

Thanks @sbrupert for the update !
Your changes look good, I'll try to test it on my side in the next few days :)

[AtaxyaNetwork]

Hi !

So I just finished torturing testing your PR, and everything is working as expected !

For me, we can merge this.
Poke @nathanael-h