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]: Align module params with the equivalent Terraform module and NITRO #442

Open
gusmb opened this issue Jun 14, 2024 · 0 comments
Assignees

Comments

@gusmb
Copy link

gusmb commented Jun 14, 2024

Summary

I am trying to maintain a custom role where I aim to provide support for both Terraform and Ansible configuration backends. I find important to keep the module specs consistent between the 2 tools, so that it becomes trivial to auto-generate the corresponding code. Right now it is not the case for a couple of parameters which are not aligned with the NITRO expected key.

Module: servicegroup_servicegroupmember_binding

The “state” parameter only supports present or absent. This is OK to instruct Ansible to create/update or delete, but actually state should also support ENABLED or DISABLED, which is what NITRO expects the state param to be, to indicate the actual admin state of the binding. This is supported in Terraform, but not in Ansible. What do you think about extending the “state” param here to support the ENABLED or DISABLED binding?

Module: servicegroup_lbmonitor_binding

For this module, the NITRO attribute is “monitorname”, and this is also the case on the corresponding terraform module. However, for some reason the Ansible module expects the parameter to be “monitor_name”, with an underscore. This makes it difficult to work with as it is inconsistent between the 2 tools.

Module: gslbservicegroup_gslbservicegroupmember_binding

Same as the first, the “state” parameter only supports present or absent, but it also needs to support ENABLED and DISABLED to be able to idempotently configure a member binding with ENABLED/DISABLED state. ENABLED/DISABLED state should then assume that the resource should be present in the configuration, with that particular state.

Issue Type

Feature Idea

Component Name

servicegroup_servicegroupmember_binding, servicegroup_lbmonitor_binding, gslbservicegroup_gslbservicegroupmember_binding

Describe alternatives you've considered

No response

Additional Information

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

2 participants