[FEATURE REQUEST]: Support for GET, GET (All) and GET filtered operations on resources

[gusmb]

Summary

In current automation workflows it is common to run some pre-checks based on intended list of Nitro resources to configure, in order to exit an automation workflow early rather than running it all the way. For instance, checking if a Vserver is already configured, or retrieving the operational status of a vserver to report back to the user whether it is up or down based on provided configuration.

We currently do this using the citrix.adc by running nitro_request queries for "show" commands:

• GET a single instance of a resource matching all parameters
• Run a GET query with filter to retrieve list of resources matching all provided parameters. Here we have to come around a limitation of Nitro, where the filter query returns matches on ANY of the parameters and not ALL of them. I am interested on matches on ALL parameters I give to the filter query

As an idea, would be nice to extend the current modules to provide the ability to retrieve the operational status of the resources instead of just looking at config. This could be supported by additional state flags "shown" and "shown_filtered"

Issue Type

Feature Idea

Component Name

ALL

Describe alternatives you've considered

Looking at observability exporter and telemetry data to check on existing objects.

Additional Information

[gusmb]

@sumanth-lingappa related to this issue, a probably more appropiate option to implement the GET, GET-ALL and filter operations would be through a lookup plugin:

This is an example use case:

{# Configure backup vserver address #}
{%     if vserver_item.failover_virtual_ip is defined %}
{%         do vserver_data.attributes.update({'backupvserver': vserver_item.failover_virtual_ip}) %}
{%     endif %}

In my abstracted data, I have the option to input an IP address corresponding to a VIP to be used as failover Vserver. As part of the config generation, I would need to lookup the Vserver name based on the VIP address value, since NITRO expects a Vserver string value for “backupvserver” instead of an IP address.

So ideally I would refactor the above Jinja snippet into the following:

{# Configure backup vserver address #}
{%     if vserver_item.failover_virtual_ip is defined %}
{%         do vserver_data.attributes.update({'backupvserver': query('netscaler.adc.resource_lookup',
                                                                      filter='ipv46=' ~ vserver_item.failover_virtual_ip,
                                                                      resource_type='lbvserver',
                                                                      match_mode='all' ) | first | map(attribute='name')}) %}
{%     endif %}

• “query” or “q” in Ansible guarantees a list as return type
• “first” would get the first match, assuming in our case that there can only be 1 valid match
• “map” filter selects the right attribute to populate as string value

This lookup plugin “netscaler.adc.resource_lookup” would be a wrapper for the NITRO Get (one), Get (all) or “filter” search, where the filter params are provided as a string of comma separated key value pairs, and the resource_type indicates the api endpoint to query for the filter search.

Note the “match_mode” parameter for the filter search, which could have possible values “any” or “all”, to match on any of the provided filter params, or to match on all of them. Currently NITRO only supports a match on any approach, however, match on all is very useful and could be easily implemented in Python by doing extra filtering on the returned resources.

This would be super useful. The Terraform equivalent would be a data source resource that could be queried to get live config data to process.

[sumanth-lingappa]

Similar request as in #296 ? 🤔

[gusmb]

Similar request as in #296 ? 🤔

Similar, however lookup plugins fit better IMO, since they're callable from Jinja2 and you might need to query for data while rendering a template

[sumanth-lingappa]

Ok. good point. I am exploring this request. Are you aware of any other collection implementation of the lookup plugin? That will be helpful.

[sumanth-lingappa]

I guess I found many lookup plugin implementations at https://docs.ansible.com/ansible/latest/collections/index_lookup.html

[gusmb]

I guess I found many lookup plugin implementations at https://docs.ansible.com/ansible/latest/collections/index_lookup.html

Netbox has a good lookup query plugin:

https://docs.ansible.com/ansible/latest/collections/netbox/netbox/nb_lookup_lookup.html

[gusmb]

Hi @sumanth-lingappa, how is this coming along? The lookup plugin would be very useful for a feature I'm working on

[M1gh7yP1r473]

Any news here? Would be a nice feature to get informations before changing anything as a precheck or just for further decisions how to proceed. Yes there is a way to get this with other methods but I am already connected with this module so why not just use it to get values from the device?