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

[FEATURE REQUEST] _info modules #296

Open
fa-elepape opened this issue Nov 2, 2023 · 3 comments
Open

[FEATURE REQUEST] _info modules #296

fa-elepape opened this issue Nov 2, 2023 · 3 comments

Comments

@fa-elepape
Copy link

Is your feature request related to a problem? Please describe.
While the new collection lets Ansible manage pretty much all aspects of Netscaler, it's not currently possible to retrieve information from them.

In my current case, I'm attempting to renew certificates which are relatively close to expiry but retrieving that information is not readily available from _info modules (see vmware.vmware_rest for an example) which means I have to fall back to using the ansible.builtin.uri module to perform those requests.

I'm raising this feature request to make this more "Ansibly" but it's clearly not a blocker.

Describe the solution you'd like
Add corresponding _info modules to the existing modules.

Describe alternatives you've considered
Again, this is not (for me) a blocking issue since I can perform the requests manually for now, it's just more cumbersome.

@sumanth-lingappa
Copy link
Collaborator

@fa-elepape, thank you for the enhancement request. This is a very apt ask.
We will definitely keep this in our planning.

Can you please share your workaround using ansible.builtin.uri which you mentioned?

@fa-elepape
Copy link
Author

fa-elepape commented Nov 15, 2023

Sure! It's really just a dump of the /sslcertkey endpoint of the NITRO API which can then be manipulated using Ansible. It's quite close to what was documented in the citrix.adc branch.

ansible.builtin.uri:
  url: "{{ nitro_protocol }}://{{ nsip }}/nitro/v1/config/sslcertkey"
  method: GET
  status_code: 200
  return_content: yes
  headers:
    X-NITRO-USER: "{{ nitro_user }}"
    X-NITRO-PASS: "{{ nitro_pass }}"
  validate_certs: "{{ validate_certs }}"
vars:
  nitro_pass: "{{ netscaler_nitro_pass | default(lookup('ansible.builtin.env', 'NETSCALER_NITRO_PASS', default=omit)) }}"
  nitro_protocol: "{{ netscaler_nitro_protocol | default(lookup('ansible.builtin.env', 'NETSCALER_NITRO_PROTOCOL')) }}"
  nitro_user: "{{ netscaler_nitro_user | default(lookup('ansible.builtin.env', 'NETSCALER_NITRO_USER', default=omit)) }}"
  nsip: "{{ netscaler_nsip | default(lookup('ansible.builtin.env', 'NETSCALER_NSIP', default=omit)) }}"
  validate_certs: "{{ netscaler_validate_certs | default(lookup('ansible.builtin.env', 'NETSCALER_VALIDATE_CERTS', default=omit)) }}"

@gusmb
Copy link

gusmb commented Jun 14, 2024

This is close to #372. I think an Ansible lookup plugin could be a better fit for this. Lookup plugins to run any sort of query for data can be used within an Ansible task, but also directly with Jinja templates, and there might be situations where the query is built on runtime during a template rendering. Lookups are powerful and support Ansible loops as well.

Here an example of how a resource lookup query could be run #372 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants