Closed mavack closed 1 year ago
Hi @mavack ! I would like to avoid adding such normalization logic to the provider, as the resources are meant to be more or less 1:1 representations of the DME objects. Nevertheless this could be implemented in a custom Terraform Module if required.
@danischm I had that debate myself. Should it be handled at the module level Or should be be handled at the provider level
Vlan trunking on the interface as a single command as a whole does not really fit into automation structure, since you cannot create a vlan attachment as a resource in its current working form.
You can create the vlan as a resource give it a name, but to assign it to a port you need to go through a whole heap of logic to read, update, write as a DME object that is probably best suited at the provider level.
And updating the vlan on the port elseware would create sync issues.
There are no plans for now to change this. If required the workaround is to normalize it at the module level.
combination bug/feature request
currently this provider uses the DME-API interface and i'm not sure if its supported via that, but can see its supported via the NXAPI-CLI method and via cli.
can we have add and remove vlans from switchport trunk groups. (switchport trunk allowed vlan add/remove)
the DME interface overwrites the entire vlan list regardless of what is listed. Which means to be safe you need to read it back, add a vlan and then sort to avoid a situation where you are somehow out of sync with the network.
This is compounded by the fact that the trunk_vlans requires a sorted list, so the read back and add and remove logic is also not simple.
so this is fine trunk_vlans = "10,100,200"
this is not and throws an error. trunk_vlans = "200,10,100"