Add more efficient facts download for cv_facts_v3

[gusmb]

Enhancement summary

Add option to download facts based on a specific list of resources (devices, containers, configlets) instead of regex based. Regex based search uses cvprac to download everything and then filter based on regex match. Requesting new method to only download resources based on given input list

Which component of AVD is impacted

cv_facts_v3

Use case example

Following role task convenient, but currently really inefficient:

- name: Load device configlets
  delegate_to: "{{ primary_cvp_host }}"
  arista.cvp.cv_facts_v3:
    facts:
      - configlets
    regexp_filter: "^{{ inventory_hostname }}(-custom|.cfg)?$"
  register: facts_configlets

The task runs for every device and my intention was to retrieve only the relevant configlet for that device. I do this for all devices and several deployments simultaneously. I found out that CVP crashes with a "Service unavailable" error as it cannot handle that much. The Provisioning tab shows a flash "Server not responding" notification for some minutes. Looking at the source code I saw that regex filter does not apply for the API call but just for filtering in the Ansible module afterwards. This forces me to re-write my tasks in a less convenient/straightforward way

Describe the solution you'd like

An option to specify a facts filter that would actually apply to the cvprac API call, based on specific items to fetch from CVP instead of regex:

- name: Load device configlets
  delegate_to: "{{ primary_cvp_host }}"
  arista.cvp.cv_facts_v3:
    facts:
      - configlets
    filter:
     - "{{ inventory_hostname }}.cfg"
     - "{{ inventory_hostname }}-custom.cfg"
  register: facts_configlets

This would run for each device and would only fetch the desired configlets from CVP in sequence, instead of the whole set (could be hundreds of them with hundreds of lines) of configlets

Describe alternatives you've considered

Refactoring my task to download all configlets for all devices at once in one play, and use a second play to process them based on available facts

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 15 days

[gusmb]

Was there plan to implement something here? I see the issue was tagged but is has been closed automatically

[ClausHolbechArista]

@gusmb we are working on some new cloudvision integration code, and as part of that we would have to implement a new plugin to fetch information from CloudVision to Ansible. Do you have any preferences for an action plugin/module vs one or more lookup plugins?

[gusmb]

@gusmb we are working on some new cloudvision integration code, and as part of that we would have to implement a new plugin to fetch information from CloudVision to Ansible. Do you have any preferences for an action plugin/module vs one or more lookup plugins?

I would need more details, but in general this is one or multiple queries to Cloudvision, storing the result on a variable, so a lookup filter would work. In general the lookup can be used in different ways, including inside Jinja templates, so probably this is the most flexible approach