netscaler
[FEATURE REQUEST]: Do not fail on non-updatable module attributes
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
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.
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
@gusmb, can you please help me to reproduce your scenario by providing me a simple fully working playbook?
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.
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.
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
Thanks for doing this, however this is not better than what we had before. Not failing the job and not reaching the desired state can lead to confusion. This is a good to have feature but then it would be better to introduce a flag, something like "nitro_error": error|warning|ignore (defaulting to error), so that we can effectuvely fail if things have not happened.
My original request was to make this declarative, mimicking the terraform behavior. I.e, on non-updatable attribute, delete and re-create, including required dependencies so that the desired state is reached.
@gusmb, As of my knowledge, in terraform, only if we change entity 'name' change is pushed, terraform is recreating the resource and applying it to the machine. Whereas any other non-updatable resource, terraform throws an error mentioning the error to the user.
@gusmb, As of my knowledge, in terraform, only if we change entity 'name' change is pushed, terraform is recreating the resource and applying it to the machine. Whereas any other non-updatable resource, terraform throws an error mentioning the error to the user.
I haven't seen any errors (non-bugs) in Terraform. the resources are re-created when needed and updated when an attribute is updateable (e.g., lbmethod change from ROUNDROBIN to LEASTCONNECTION) does not trigger a re-creation of the resource, but changing a servicegroup port does. Errors are a symptom of the imperative behavior