Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

folder_moid_lookup not working consistently #324

Closed
robbevl opened this issue Apr 29, 2022 · 5 comments
Closed

folder_moid_lookup not working consistently #324

robbevl opened this issue Apr 29, 2022 · 5 comments
Labels
bug This issue/PR relates to a bug waiting_on_contributor Needs help. Feel free to engage to get things unblocked

Comments

@robbevl
Copy link

robbevl commented Apr 29, 2022

Sometimes, a folder 4 levels deep is not found, the lookup then returns an empty string.

Our folderstructure looks like this:
/DC/Applications/MYAPP/PRD

/DC/Applications/MYAPP is found, and MOID returned.
/DC/Applications/MYAPP/PRD is not found

If I create /DC/Applications/MYAPP/PROD it is found.
If that folder is then renamed to /DC/Applications/MYAPP/PRD the plug can't find it any more.

I'm not sure what the issue is:

  • It's not the all caps, because it can find /DC/Applications/MYAPP/TESTING
  • It's not three letter named, cause it can find /DC/Applications/MYAPP/RND
  • It's not even PRD and TST being "special" because it can find /DC/Applications/MYAPP2/PRD. Then again, /DC/Applications/MYAPP2/PROD couldn't be found

It looks totally random, but it's always four levels deep, and once it decides it can't find a name it will never find that name, not even if you delete and recreate the folder, or if you rename a folder that can be found.

Note that vmware.vmware_rest.vcenter_folder_info can find those problematic folders.

If someone can help me pinpoint this I'm all ears.
I'll use a workaround like this for now:

- name: Get folder
  vmware.vmware_rest.vcenter_folder_info:
    vcenter_hostname: "{{ vcenter_hostname }}"
    filter_names:
      - "{{ deploy_folder | basename }}"
    parent_folders:
      - "{{ lookup('vmware.vmware_rest.folder_moid', deploy_folder | dirname) }}"
  register: my_folder

"{{ my_folder.value[0].folder }}"
gives me then the same value as I expected from
"{{ lookup('vmware.vmware_rest.folder_moid', deploy_folder) }}"

@robbevl
Copy link
Author

robbevl commented Apr 29, 2022

While the workaround is working, I noticed that other lookups have the same issue..
I have no choice but convert our deployscript to community.vmware :(

@goneri
Copy link
Member

goneri commented May 2, 2022

Thank you @robbevl for the bug report. What version of vSphere do you use?

@goneri goneri added the bug This issue/PR relates to a bug label May 2, 2022
@goneri
Copy link
Member

goneri commented May 2, 2022

I've tried to reproduce the problem with the following tasks:

- name: Create the Applications folder
  community.vmware.vcenter_folder:
    datacenter_name: my_dc
    folder_name: Applications
    folder_type: vm
    state: present
- name: Create the MYAPP folder
  community.vmware.vcenter_folder:
    datacenter_name: my_dc
    folder_name: MYAPP
    folder_type: vm
    parent_folder: Applications
    state: present
- include_tasks: create_delete.yaml
  with_sequence: start=0 end=400 stride=1

and this is the create_delete.yaml:

- name: Create the PRD folder
  community.vmware.vcenter_folder:
    datacenter_name: my_dc
    folder_name: PRD
    folder_type: vm
    parent_folder: Applications/MYAPP
    state: present
- vcenter_folder_info:
  register: a
- debug: var=a
- set_fact:
    level1: "{{ lookup('vmware.vmware_rest.folder_moid', '/my_dc/vm/Applications') }}"
    level2: "{{ lookup('vmware.vmware_rest.folder_moid', '/my_dc/vm/Applications/MYAPP') }}"
    level3: "{{ lookup('vmware.vmware_rest.folder_moid', '/my_dc/vm/Applications/MYAPP/PRD') }}"

- debug:
    msg: "level1 {{ level1 }}, level2 {{ level2 }}, level3: {{ level3 }}"
- assert:
    that:
      - "level1 != ''"
      - "level2 != ''"
      - "level3 != ''"

- name: Delete the PRD folder
  community.vmware.vcenter_folder:
    datacenter_name: my_dc
    folder_name: PRD
    folder_type: vm
    parent_folder: Applications/MYAPP
    state: absen

This is not enough to reproduce the problem here (vSphere 7.0.3). Can you try on your side to confirm this is enough to trigger the error.

@goneri goneri added the waiting_on_contributor Needs help. Feel free to engage to get things unblocked label May 2, 2022
@robbevl
Copy link
Author

robbevl commented May 4, 2022

Hi, thanks for taking the time to look into this!
We're on vSphere 7.0.3.00300.

I adapted the tasks slightly (needed to provide custom vcenter_hostname and user, also provided our actual dc name), but it did fail on the first iteration:

TASK [set_fact] ********************************************************************************************************
ok: [localhost]

TASK [debug] ***********************************************************************************************************
ok: [localhost] =>
  msg: 'level1 group-v2003, level2 group-v21760, level3: '

TASK [assert] **********************************************************************************************************
fatal: [localhost]: FAILED! => changed=false
  assertion: level3 != ''
  evaluated_to: false
  msg: Assertion failed

Here's the literal playbook I used (minus vsphere login info).

test_moid.yml:

---


- name: Test folder MOID
  hosts: localhost
  gather_facts: False
  vars:
    vcenter_hostname: <removed>
    vcenter_username: <removed>
    vcenter_password: <removed>
  tasks:

    - name: Create the Applications folder
      community.vmware.vcenter_folder:
        hostname: "{{ vcenter_hostname }}"
        username: "{{ vcenter_username }}"
        password: "{{ vcenter_password }}"
        datacenter_name: NLDTC1
        folder_name: Applications
        folder_type: vm
        state: present

    - name: Create the MYAPP folder
      community.vmware.vcenter_folder:
        hostname: "{{ vcenter_hostname }}"
        username: "{{ vcenter_username }}"
        password: "{{ vcenter_password }}"
        datacenter_name: NLDTC1
        folder_name: MYAPP
        folder_type: vm
        parent_folder: Applications
        state: present

    - include_tasks: test_create_delete.yml
      with_sequence: start=0 end=400 stride=1

test_create_delete.yml:

---

- name: Create the PRD folder
  community.vmware.vcenter_folder:
    hostname: "{{ vcenter_hostname }}"
    username: "{{ vcenter_username }}"
    password: "{{ vcenter_password }}"
    datacenter_name: NLDTC1
    folder_name: PRD
    folder_type: vm
    parent_folder: Applications/MYAPP
    state: present
- vmware.vmware_rest.vcenter_folder_info:
    vcenter_hostname: "{{ vcenter_hostname }}"
    vcenter_username: "{{ vcenter_username }}"
    vcenter_password: "{{ vcenter_password }}"
  register: a
- debug: var=a
- set_fact:
    level1: "{{ lookup('vmware.vmware_rest.folder_moid', '/NLDTC1/Applications', vcenter_hostname=vcenter_hostname, vcenter_username=vcenter_username, vcenter_password=vcenter_password) }}"
    level2: "{{ lookup('vmware.vmware_rest.folder_moid', '/NLDTC1/Applications/MYAPP', vcenter_hostname=vcenter_hostname, vcenter_username=vcenter_username, vcenter_password=vcenter_password) }}"
    level3: "{{ lookup('vmware.vmware_rest.folder_moid', '/NLDTC1/Applications/MYAPP/PRD', vcenter_hostname=vcenter_hostname, vcenter_username=vcenter_username, vcenter_password=vcenter_password) }}"

- debug:
    msg: "level1 {{ level1 }}, level2 {{ level2 }}, level3: {{ level3 }}"
- assert:
    that:
      - "level1 != ''"
      - "level2 != ''"
      - "level3 != ''"

- name: Delete the PRD folder
  community.vmware.vcenter_folder:
    hostname: "{{ vcenter_hostname }}"
    username: "{{ vcenter_username }}"
    password: "{{ vcenter_password }}"
    datacenter_name: NLDTC1
    folder_name: PRD
    folder_type: vm
    parent_folder: Applications/MYAPP
    state: absent

Only actual difference I can see with what you did is the dc name (not sure it is relevant).
Also, you added a "vm" folder in your lookup : /my_dc/vm/Applications.

softwarefactory-project-zuul bot pushed a commit that referenced this issue Sep 9, 2024
SUMMARY
This change rewrites the lookup plugin logic to use a top down approach to finding objects. The plugins will now step through an objects path and try to lookup each intermediate object until it gets to the final object.
The old method has a few issues:

The existing plugins use an incorrect search method  which yield inconsistent results (as described in #500)
They also cannot find resources with the same name, even if the paths given are unique. For example, if /datacenter/vms/my-folder and /datacenter/hosts/my-folder both exist, you can never find either one
Items with the same name will cause conflicts, even if those items have slightly different paths. For example: /datacenter/vms/foo and /datacenter/hosts/foo  existing at the same time makes it difficult to search for either folder

Fixes:
#500
#445
#324
ISSUE TYPE

Bugfix Pull Request

COMPONENT NAME
all lookup plugins
ADDITIONAL INFORMATION
The original top down approach is described in #445. I tried to get that version working but ran into a few issues.

Reviewed-by: Danielle Barda
Reviewed-by: Ondra Machacek <machacek.ondra@gmail.com>
Reviewed-by: mikemorency
@mikemorency
Copy link
Collaborator

This issue should be resolved in the next release. Please see #500 for more details

agonzalezrh added a commit to redhat-cop/agnosticd that referenced this issue Sep 14, 2024
…d folder_moid

We are hitting the following bug:

ansible-collections/vmware.vmware_rest#324

This is a workaround till new version of the vmware.vmware_rest will be released
agonzalezrh added a commit to redhat-cop/agnosticd that referenced this issue Sep 15, 2024
…d folder_moid (#8551)

* [ocp4_workload_virt_roadshow_vmware] Using vcenter_folder_info instead folder_moid

We are hitting the following bug:

ansible-collections/vmware.vmware_rest#324

This is a workaround till new version of the vmware.vmware_rest will be released

* Update vcenter_setup_create_folder_and_vms.yml

* Update vcenter_setup_create_folder_and_vms.yml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue/PR relates to a bug waiting_on_contributor Needs help. Feel free to engage to get things unblocked
Projects
None yet
Development

No branches or pull requests

3 participants