Generic NetScaler Ansible module for NetScaler Automation

Citrix Ansible modules for NetScaler are hosted in this GitHub repository. There you will find an assortment of modules that utilize a specific NITRO API endpoint. Each of these resources will implement a CRUD lifecycle for each endpoint taking into account the peculiarities that particular endpoint may have. While this model is fine it requires for each endpoint the creation of a module that may have many similarities to existing ones. Hence, we have a generic module citrix_adc_nitro_resource which implements the CRUD operations in a generic manner applicable to multiple endpoints. You can use generic module citrix_adc_nitro_resource if you dont find a dedicated module for the usecase you are targeting.

How NetScaler Nitro Resource module works ?The citrix_adc_nitro_resource module will accept as parameters a dictionary which describes the workflow of the endpoint the attributes for this particular endpoint and the attributes required to connect to the target NetScaler. Then it will compare the local and remote state and decide on the operation it needs to perform. It will update the changed status variable and report this back to Ansible. Let’s see what a typical use of the module looks like :

   - name: Setup nitro resource lb group      delegate_to: localhost      citrix_adc_nitro_resource:        nsip: "{{ nsip }}"        nitro_user: "{{ nitro_user }}"        nitro_pass: "{{ nitro_pass }}"             state: present         workflow:    lifecycle: object    endpoint: lbgroup    primary_id_attribute: name    resource_missing_errorcode: 258    allow_recreate: true        resource:          name: mylbgroup          timeout: 160

The invocation of the module is very similar to the other modules. It takes the connection information for the NITRO API, the state variable which will determine if the NITRO object must be created/updated, or destroyed.

Additionally, it takes the workflow variable which is a dictionary that will decide what NITRO API calls to make to implement the CRUD operations. This dictionary is the one that will differentiate the execution for the various endpoints and make the correct checks for the existence and equality of the local and remote states.

The most important attribute is the lifecycle attribute which will determine the code path taken inside the module. The endpoint attribute is the one that determines the url that will be used for this NITRO object. The rest of the attributes have a special meaning depending on the lifecycle attribute. In this case we can see that name is the attribute that uniquely identifies this NITRO object, 258 is the error code returned when the resource is missing, and allow_recreate defines that should a recreate instead of an update operation is needed it is allowed.

The values for this dictionary could be provided by the user but since this requires an intimate knowledge of the NITRO API and the code of the nitro_resource module we provide a reference for this dictionary in our github repository. It can be found here.

You can use it in your playbook by referencing it as a variable

  vars_files:    - deps/workflows.yaml…         workflow: "{{ workflow.lbgroup }}"

Finally, it takes the resource option which is the dictionary containing the attributes of the NITRO object.

In this dictionary, we define the NITRO object attributes. You need to know which attributes are applicable for each endpoint. The reference for the NITRO API can be found here.

Additionally for the CRUD operations to work correctly the attributes must be the same data type as returned by the NITRO API. For example, a number that is returned as a string must be provided as a string in this dictionary. Otherwise, the module will report that the configured object is not the same as the remote object on the target NetScaler.

Limitations 

As an example, the enable/disable action for a basic server cannot be implemented with the nitro_resource module.

For this, the user will have to use the other generic module we have citrix_adc_nitro_request, which we have covered in a separate post.

Useful Links

Nitro resource examples ( https://github.com/citrix/citrix-adc-ansible-modules/tree/master/samples/nitro_resource )

Nitro request examples ( https://github.com/citrix/citrix-adc-ansible-modules/tree/master/samples/nitro_request )