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]: Do not fail on non-updatable module attributes #373

Open
gusmb opened this issue Feb 29, 2024 · 6 comments
Open

[FEATURE REQUEST]: Do not fail on non-updatable module attributes #373

gusmb opened this issue Feb 29, 2024 · 6 comments
Assignees

Comments

@gusmb
Copy link

gusmb commented Feb 29, 2024

Summary

I am trying to use the collection modules and seen several error messages suggesting that was caused by non-updatable attributes.
In a declarative approach, I would like to be able to adjust the module behavior in this case to simply delete the old object and create it again with the new attributes, rebuilding any bindings that the old resource had.

Issue Type

Feature Idea

Component Name

lbvserver, service, servicegroup, lbmonitor, gslbvserver, gslbservice, gslbservicegroup

Describe alternatives you've considered

No response

Additional Information

@sscottkeefe
Copy link

Does this relate to an issue I just came across where the servicegroup module is telling me the servicegroup_servicegroupmember_binding resource already exists, so it won't make any changes? I don't think this was occurring in 2.4.0/the latest Git code prior to 2.5.0. It will make changes that involve removal of members, but it won't let me add.

@gusmb
Copy link
Author

gusmb commented Mar 1, 2024

This actually relates to failures of the modules when we try to update non-updatable attributes. For instance, a servicegroup protocol field or the servicegroup IP. As long as the primary key is provided. the right way to handle this declaratively is to identify that the resource needs to be re-created because of updating non-updatable attributes, rebuilding the required bindings afterwards. This is default behavior in Terraform, but in this case Ansible fails with an error message "cannot change value for the following non-updatable attributes ['ip']", which is more like imperative behavior from Nitro

@sumanth-lingappa
Copy link
Collaborator

@gusmb, can you please help me to reproduce your scenario by providing me a simple fully working playbook?

@sumanth-lingappa
Copy link
Collaborator

In a declarative approach, I would like to be able to adjust the module behavior

fair point. I agree with this. I will check what can be done to implement this behaviour.

@sscottkeefe
Copy link

This actually relates to failures of the modules when we try to update non-updatable attributes. For instance, a servicegroup protocol field or the servicegroup IP. As long as the primary key is provided. the right way to handle this declaratively is to identify that the resource needs to be re-created because of updating non-updatable attributes, rebuilding the required bindings afterwards. This is default behavior in Terraform, but in this case Ansible fails with an error message "cannot change value for the following non-updatable attributes ['ip']", which is more like imperative behavior from Nitro

Gotcha, I don't think my situation is related, then; I'll spin off to a separate submission. Thanks.

@gusmb
Copy link
Author

gusmb commented Jun 14, 2024

Is there any work planned around this issue? Currently, the non-updatable attributes break the idempotency and declarative nature of the modules. I think this is a key feature for the collection, otherwise there isn't really much difference between using the collection or the Nitro API directly

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

When branches are created from issues, their pull requests are automatically linked.

3 participants