vmware.vmware_rest.vcenter_ovf_libraryitem - Update existing template

[sepetuks]

SUMMARY

I am trying to update existing OVF template but it looks it is not updating it when I provide library_item_id.
All works ok when I need first OVF template to be cloned to library but I do not succed updateing Connten library template with new versions.
As per documentation"
- library_item_id (str): Identifier of the library item that should be should be updated. (['present'])
https://github.com/ansible-collections/vmware.vmware_rest/blob/main/docs/vmware.vmware_rest.vcenter_ovf_libraryitem_module.rst
Per documentation I read it should be possible. So I either thats issue with documentation or with code.

ISSUE TYPE

• Bug Report

COMPONENT NAME

vmware.vmware_rest.vcenter_ovf_libraryitem

ANSIBLE VERSION

ansible [core 2.13.7]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/henris/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/henris/.local/lib/python3.8/site-packages/ansible
  ansible collection location = /home/henris/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/henris/.local/bin/ansible
  python version = 3.8.10 (default, Nov 14 2022, 12:59:47) [GCC 9.4.0]
  jinja version = 3.1.2
  libyaml = True

COLLECTION VERSION

Collection         Version
------------------ -------
vmware.vmware_rest 2.2.0

CONFIGURATION

OS / ENVIRONMENT

vCenter 7.0 Update 3j (20990077)

STEPS TO REPRODUCE

    - name: Export the VM as an OVF on the library (new)
      vmware.vmware_rest.vcenter_ovf_libraryitem:
        vcenter_hostname: "{{ vcenter_hostname }}"
        vcenter_username: "{{ vcenter_username }}"
        vcenter_password: "{{ vcenter_password }}"
        vcenter_validate_certs: false
        vcenter_rest_log_file: '/tmp/rest.log'
        session_timeout: 2900
        source:
          type: VirtualMachine
          id: '{{ vm1_info.id }}'
        target:
          library_id: '{{ library_id }}'
        create_spec:
          name: golden
          description: an OVF example
          flags: []
        state: present
      delegate_to: localhost  
      tags: library

   - name: Export the VM as an OVF on the library (update)
      vmware.vmware_rest.vcenter_ovf_libraryitem:
        vcenter_hostname: "{{ vcenter_hostname }}"
        vcenter_username: "{{ vcenter_username }}"
        vcenter_password: "{{ vcenter_password }}"
        vcenter_validate_certs: false
        vcenter_rest_log_file: '/tmp/rest.log'
        session_timeout: 2900
        source:
          type: VirtualMachine
          id: '{{ vm1_info.id }}'
        target:
          library_id: '{{ library_id }}'
          library_item_id: '{{ library_item_id }}'
        create_spec:
          name: golden
          description: an OVF example2
          flags: []
        state: present
      delegate_to: localhost  
      tags: library

EXPECTED RESULTS

I would expect second task would do OVF template update, but task just finished without actions (no failure)

ACTUAL RESULTS

Second task is always giving status "ok" (I would expect changed)

TASK [Export the VM as an OVF on the library (new)] ********************************************************************
changed: [Template -> localhost]

TASK [Export the VM as an OVF on the library (update)] *****************************************************************
ok: [Template -> localhost]

[rgadwagner]

I'll add the "me too" to this.

1. The documentation identifies library_id as unused if library_item_id is passed in, but without library_id the process fails with invalid values.
2. WHen passing both library_id and library_item_id the process behaves as if ONLY library_id is passed and attempts to create the OVF container object before uploading to it. If the OVF container object exists, ansible returns "green" and does nothing.

[smatterchew]

Ran into the same problem. Sending an updated image to the local CL results in changed: false and the new image isn't exported to the local CL.

[user@ansible] ➤ ansible --version 
ansible [core 2.11.12]
  config file = /home/user/.ansible.cfg
  configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /opt/ansible/os9_prov_vmw_20230117/lib64/python3.6/site-packages/ansible
  ansible collection location = /home/user/.ansible/collections:/usr/share/ansible/collections
  executable location = /opt/ansible/os9_prov_vmw_20230117/bin/ansible
  python version = 3.6.8 (default, Aug 13 2020, 07:46:32) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
  jinja version = 3.0.3
  libyaml = True

Also using 2.2.0 of the collection:

[user@ansible] ➤ ansible-galaxy collection list | grep vmware_rest
vmware.vmware_rest    2.2.0

I am able to send the image to vCenter and manually "update" the version in the CL.

Workaround for now is to delete the image from the local CL and allow the task to re-create it.

vSphere: vSphere Client version 7.0.3.01100

[rgadwagner]

Can confirm this is functional on 2.1.5 of VMWare Rest Library. Downgrading to 2.1.5 in a collections/requirements.yml will provide full functionality in pushing uploads of OVF to VMware.

collections/requirements.yml:

• name: vmware.vmware_rest
  version: 2.1.5

Then Run:
ansible-galaxy collection install -f -r collections/requirements.yml -p collections

(The above installs the collections to a local "collections" directory in your repo, YMMV on the above command).

This will install 2.1.5 of the rest collection into ansible and you should see things work from there. You will need to pass in BOTH library_id AND library_item_id to get it to function (Their documentation is also dead wrong with no examples).

[rgadwagner]

So...we've now released 3.0, but no one can upgrade to it that's using library functionality because this bug still exists?

[billy-stellar]

Is there a replacement for this module in vmware.vmware? I'm having the same issue, it's not 'changing' and updating the existing template. Maybe @mikemorency has some info on this one?

[mikemorency]

unfortunately i dont see a module that can act as a work around for this particular issue. Ill investigate in the next couple of days and see what options we have to resolve the issue

[billy-stellar]

@mikemorency I found something by mistake. If I try to update an existing template by including target.template_item_id, but I use a create_spec.name that's different than the existing template, it updates/changes. The template name is not honoring the create_spec.name.

The name of the template was "Windows Server 2022 Datacenter". It updated the template per the task result below, but the template name remained the same (no ' - Nov 2024').

value:
ovf_library_item_id: 0f111d4c-19a3-462b-ae1a-724aebcff1a0
error:
warnings: []
information: []
errors: []
succeeded: true
changed: true
invocation:
module_args:
source:
type: VirtualMachine
id: vm-314
target:
library_id: c4f2c94f-3918-4c2c-bf3a-a5b609f4fbcb
library_item_id: 0f111d4c-19a3-462b-ae1a-724aebcff1a0
create_spec:
name: Windows Server 2022 Datacenter - Nov 2024
description: >-
Windows Updates current to 11/27/2024. Image has been optimized for VM
use. Chrome and Edge browsers are pre-installed.
flags:
- EXTRA_CONFIG

Update: It still works as expected with the create_spec.name commented out. So, include the name if you're making a net new template, exclude the name and include an id if you're updating an existing. The description updates as well, but the name does not. I think just the docs need updating unless something new to replace this is coming to vmware.vmware.

[mikemorency]

Part of the issue is that the REST endpoint does not support updating template metadata without re-creating the template, see here. The other part of the issue is that the generated module code uses just the create_spec.name attribute to validate if the template exists already.

Long term, this module is not ideal and should be re-written in vmware.vmware. Short term, the workaround given by @billy-stellar will work for updating the description. I will update the module's examples and description in the next release to reflect this quirk and leave this issue open as a reminder to migrate the modules functionality eventually.