-
Notifications
You must be signed in to change notification settings - Fork 10
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
are lists not lists but ordered sets? #243
Comments
Some additional digging: I think I saw similar behavior when I was doing import of a feature template where same device model was listed twice (possible when playing with APIs!) and terraform complained that it was an incorrect set (while it was a list) |
|
I might be making a very global statement... but based on YANG model, I don't believe that anything in schema is a "set". I'd be curious to see an example where SD-WAN data structure is actually is a set, not a list (maybe I am wrong? :) ) |
Unfortunately, there are no YANG models available for this. I was referring to this schema for example: https://github.com/CiscoDevNet/terraform-provider-sdwan/blob/main/gen/models/feature_templates/cisco_system.json The device (type) list for example is a "set" as the order of device types is not relevant. In general, having a "list" where the order is not significant can cause issues as well, like for example if the GUI "reorders" the elements TF will try to reconcile it, whereas it is semantically the same. So it needs to be determined on a case by case basis. Anyway, if you find other instances where it should be a "list", please let us know and we will fix it. |
It is not necessarily about duplicates, which even though the API accepts them, they do not make sense in the context of device types. The important part is, the order of elements is of no significance, therefore if the backend/UI changes the order of elements and we would be using a "list" type, TF would continuously detect this as a change, trying to reorder them, even though it is semantically the same configuration. |
Change type of |
I understand your approach but, again, it leads to mismatches (like above, TF fails with error where vManage is handling it fine). |
In terms of other examples, right away, [affinity_group_preference] under sdwan_cisco_system_feature_template is also a "Set" while it should be an ordered list (order matter) |
Symptom:
in sdwan_cisco_system_feature_template resource, change
and the reported outcome is "No changes. Your infrastructure matches the configuration."
However, the order is important as router walks them sequentially, so it's a different configuration
The text was updated successfully, but these errors were encountered: