gusmb
commented
7 months ago @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
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:
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