Support important AS3 API features in 'bigip_as3_deploy' module

[sohel-m]

Firstly thanks to the team for developing this module, in my opinion it was much needed to have this declarative collection in addition to the already existing imperative one.

Is your feature request related to a problem? Please describe.

The is the official documentation page for 'bigip_as3_deploy' module.
https://clouddocs.f5.com/products/orchestration/ansible/devel/f5_bigip/modules_2_0/bigip_as3_deploy_module.html#bigip-as3-deploy-module-2

I see it has very 'limited features' as compared to what the AS3 API provides.

• Currently it does not provide a way get the 'current' AS3 configuration on the BIGIP.

• It does not provide a way to enforce a dry-run or control loglevel or trace response.
  https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/refguide/schema-reference.html#controls

• It does not seem to support per-app declarations

Describe the solution you'd like

At my organization we are aiming to implement a production level workflow for AS3 deployment to our BIGIP clusters.
The process would be GitOps driven, where for a particular change/pull request scope will be limited to per-app and there would be a dry-run stage(to evaluate the diff of the change being deployed) and it would proceed with actual deployment once checks are fine.

Describe alternatives you've considered

The alternative is to directly utilize the AS3 API with built-in ansible modules like uri (instead of utilizing the 'bigip_as3_deploy' module) and structuring the playbook flow as described above.

Additional context

I'm quite sure there may already be on-going work to incorporate the above functionality to the module.
In this case could you please remark on when it would be generally available or if it is not planned the reasons for its exclusions?

Thanks again :)

[pgouband]

Hi @sohel-m,

Thank you for your feedback.

It does not provide a way to enforce a dry-run or control loglevel or trace response.

Controls are part of the AS3 declaration, here an example of dry-run:
https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/declarations/miscellaneous.html?highlight=dry%20run#using-dry-run-as-an-adc-controls-object

It does not seem to support per-app declarations

This feature is in our backlog but I don't have an ETA.

[sohel-m]

Hi @pgouband ,

Thanks for the reply.

This feature is in our backlog but I don't have an ETA.

Noted. Is there someplace which could be tracked for updates on this topic :) ?

Controls are part of the AS3 declaration, here an example of dry-run:

Noted that controls could be defined within the AS3 declaration.
But what this would mean for us this in our pipeline/workflow (that I described above) is following:

1. Get changed AS3 declaration file in the pull request: sample_as3.json
2. Perform file manipulation to add/update 'controls' subsection with dryrun as true
3. Call the ansible module with inputs: bigip_as3_deploy(sample_as3.json)
4. If all okay, proceed
5. Perform file manipulation to add/update 'controls' subsection with dryrun as false
6. Call the ansible module with inputs: bigip_as3_deploy(sample_as3.json)

But if dry run(and other control parameters) could be directly passed to the ansible module, the pipeline/workflow would be more convenient in my opinion, primarily because we wont need to do any file manipulation on the run

1. Get changed AS3 declaration file in the pull request: sample_as3.json
2. Call the ansible module with inputs: bigip_as3_deploy(sample_as3.json, dryrun: true)
3. If all okay, proceed
4. Call the ansible module with inputs: bigip_as3_deploy(sample_as3.json, dryrun: false))

I would greatly appreciate if this feature could be considered, it will definitely help your customers imo :)

[pgouband]

Hi @sohel-m,

We will review it.

What other customers are doing:

1. Generating two AS3, one with dry-run and one without
2. Call the ansible module using AS3 with dry-run
3. if all good, call the ansible module using AS3 without dry-run

[sohel-m]

Thanks for considering it for Review, it will indeed help to avoid dealing with 2 json files for a single workflow :)