Handling Configuration Drift

[HannesDampft]

Hello Folks,

first of all, thanks for this amazing Terraform provider! It works really well and makes it easy to get started.

Managing switch configurations with Terraform sounds great because it ensures the desired state. However, I’m struggling to understand how to effectively prevent configuration drift with the current implementation. As far as I understand, the provider only manages resources (e.g., bridges/interfaces) that are already in its state. This means that if someone manually creates a new interface or bridge, the provider won’t manage it.

I know that I can import resources into the state, but for that, I need the resource ID and a valid planned configuration. This makes it difficult to ensure consistency automatically.

I would love to see a way to either:

• Automatically import every configuration change and remove unmanaged resources on the next apply
• Automaticly remove every config, that has not been configured
• Have a built-in mechanism to detect and monitor configuration drift.

Maybe I’m missing something due to my inexperience with Terraform, or perhaps the documentation could be improved in this regard?

Looking forward to your input—thanks!

[vaerh]

Hello!

Questions similar to yours appear here from time to time. But unfortunately I can't give any encouragement and say that there is a solution to them.
The basic concept of TF is that resources should be managed without changes from the outside. TF knows exactly as much as is described in the script files and the state file.
In addition, there are two more big obstacles, in my opinion, that prevent the realization of these ideas.
The first one is that the TF itself calls the provider selectively to access certain resources. The provider itself implements standard MT console commands, so you can't get the whole list of configured resources (although maybe I don't have secret knowledge). As far as I know all the content is available only in the configuration export output, but the provider does not parsing such output.
The second is the architecture of the provider and MT itself. To make it easier for the provider to support changes in RouterOS releases, some attributes of some resources are insensitive to parameters coming from the MT side. For this reason, there is no way to track their non-TF changes. And there is currently no way to change this behavior, since we cannot affect the list and contents of attributes that are passed between MT and TF.
And so it's a good idea to fully control the integrity of the MT configuration.

[HannesDampft]

Hello,

I completely understand that keeping the state clean can be challenging, especially when users add items through the GUI or API. Is there anything else I can do to make this easier, besides just making the user read-only? How do you and your team, or others from the Community prevent drift from occurring?

I believe the answer is in your text, but I think starting a discussion could be helpful for others who face the same problem and might benefit from different perspectives within the community.

[vaerh]

In my case it's a bit easier, as I'm the only one administrating MT. That is, I follow the principle of monopoly configuration for TF managed resources.
What I can think of at the moment is to either leave your account alone with RW permissions, or go the long way and describe in the TF script all attributes of your resources that have the DiffSuppressFunc: AlwaysPresentNotUserProvided entry. You can see this in the source code of the terraform-provider-routeros/routeros provider.

[durandguru]

I have some automation. So I'm the only one that manages all te stuff and do it in Terraform. I have some people who needs to vlan or force poe. They edit an config file in git and commit, an github action then performs the change on the device. In this way the person does not need to know how the different milrotik models vlan. All handled in the module.

[javierbertoli]

As @vaerh mentions, terraform (as other configuration tools like pulumi, puppet, ansible, etc) know of the resources they manage in a target, and no others. So they can detect drift in such resources, but not in resources they know nothing of.

The idea behind this is that the targets can be modified from outside these tools (which is usually desired) but the resources under the tool's control are always kept as desired. This also allows you also to gradually manage a device, importing resources as needed.

In some of these tools you can manage some top-level resources as a block, ie, managing firewall you can manage all the rules in a single pass and, those that drift from the config are modified and those that are not in the config, deleted. But I understand routeros does not allow this to be done (all the resources are managed individually).

In my case, I use some terraform code I wrote where most resources are iterable so importing a whole new MT takes some effort but not much.

As a "marker" to know which resource is managed by terraform and which not, I automatically comment them with text that lets me identify the resources. Maybe this solution helps you too?

[HannesDampft]

Hey, i am very grateful, for the Solutions you guys provided, I was also using a comment as marker, but was hoping to find a more complete Solution. I think the Discussion has been answered, with @vaerh comment for now. Maybe MT implements something to make the state manageble better. (someone can Dream, right?)