Some boolean params can't be reset and the provider does not understand the value

[KuxaBeast]

Describe the bug
On some boolean fields of some resources the value can't be set to false and the provider does not understand the current value. This issue originates from the fact, that in the RouterOS API not all booleans are treated the same way and some need to be "unset" instead of "set" to "false". One instance is the passive parameter on the routeros_routing_ospf_interface_template resource.

The problem resides in the handling of boolean values in the data serialization code, which does not differentiate between classic boolean states and these set/unset params. This behaviour can clearly be seen in the behaviour in the ROS console or API:

[admin@Lain] > /routing ospf interface-template
[admin@Lain] > set *D passive
[admin@Lain] > print terse show-ids proplist=area,type,cost,passive where .id=*D
*D area=area-ospfv2 type=broadcast cost=1 passive
[admin@Lain] > set *D !passive
[admin@Lain] > print terse show-ids proplist=area,type,cost,passive where .id=*D
*D area=area-ospfv2 type=broadcast cost=1

In case of the REST API, it's just a matter of prefixing the PATCH's data map key with "!" to unset the value. The set/unset status is reflected in the existence of the parameter in the response json, not on its value.

[vaerh]

Hi!
Yes, unfortunately I have encountered this behavior of MT resources. The only solution I can think of is to force recreate the resource. I will take a look at your situation on my lab and see what can be done.

[KuxaBeast]

Can't this be somehow mitigated? This behavior is predictable by checking the resource parameters' table on the ROS docs/wiki (instead of yes/no, there is an empty "()" datatype). If we were to somehow implement a secondary boolean type to handle these kind of parameters, or just somehow make a toggle and annotate the affected resources in the provider code base, to handle the API differently? I am just speculating here, though. I don't know the intricacies of Go and what flexibility does the Terraform provider SDK allow...
Thanks for looking into this.

[vaerh]

Let's just say that if a fix needs to be released quickly, only a forced recreation of the resource is the way to go. If there is no hurry, we can try (with no guarantee that everything will work quickly and well) to annotate the fields requiring unset. But! this will require serious changes in the main code, which is responsible for converting TF and MT parameters.

[vaerh]

In the best tradition of MT:

[vaerh]

🎉 This issue has been resolved in version 1.20.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀