Cannot recreate template if old one (with same name) still exists

[DesignsWithDavid]

I want to use this packer plugin to create a golden template such that the same of the template is "ubuntu-golden". This template creation fails if a template of the same name already exists. However, XCP-NG does allow multiple templates of the same name to exist. In other words, this limitation (while it may or may not be good practice) is imposing a limitation that XCP-NG does not impose.

My suggestion is to change line 46 of https://github.com/ddelnano/packer-plugin-xenserver/blob/main/builder/xenserver/common/step_type_boot_command.go to find the VM by the UUID instead of by name. The UUID is already used in pausing and unpausing the VM (like on line 24 of https://github.com/ddelnano/packer-plugin-xenserver/blob/main/builder/xenserver/common/step_start_vm_paused.go).

If people still want to avoid allowing this by default, we could introduce a new config flag, such as, "allow_duplicate_templates=false".

[DesignsWithDavid]

We could even add a config option, "remove_old_templates=true" to remove the old templates with the same name before converting the successful VM to a template.

Or, a unique tag could be applied only to the latest template, such as "latest". In other words, when a new template of the same name is created, and "unique_template_tag=latest", then any other template of the same name with the tag "latest" has the tag removed, and the new template is created such that it is the only one with the tag "latest".

[ddelnano]

Hey @DesignsWithDavid, thanks for opening this issue and I think allowing the "golden template" workflow you described sounds really useful.

Are you consuming these templates via the xen orchestra terraform provider? I ask because if the packer plugin applied the "latest" unique template tag, it would be nice if the xenorchestra_template data source had the ability to filter by tags so that your terraform code would automatically pick up the new template on the next run.

How would you feel if this was implemented with the two additional config settings you mentioned above: allow_duplicate_templates and unique_template_tag? I'm not sure that removing old templates is necessary if duplicates are explicitly allowed.

[mire3212]

I've been hitting this same issue and I do use TF to deploy things.

If you were to implement allow_duplicate_templates, then I would consider how that flow works when true or false is used.

In my workflow, I don't feel it's necessary for me to keep multiple templates (assuming it's not going to break anything by deleting the existing ones; I am very new to this) so my use-case would just entail wanting to replace the existing template with the new one from Packer. This might mean allow_duplicate_templates = false, with the expectation that the existing template is overridden; this might also mean another option such as allow_template_override. That would present the following flows:

allow_duplicate_templates = false and allow_template_override = true -- Delete and Replace the template
allow_duplicate_templates = false and allow_template_override = false -- Create an error on the Packer side during build
allow_duplicate_templates = true would ignore allow_template_override and just create a new template with a new ID

---

As for the TF stuff, having some way to identify which template would be considered the latest would be very helpful when multiple templates of the same name are available (such as with allow_duplicate_templates).

This also mirrors AWS very well when choosing an AMI through Terraform as there is a most_recent flag that uses the date of creation to identify which one is newest.