Thanks for bringing this up. For me `config replace` is a clear must when it comes to generating full configs and deploying them automatically which is what nearly all of the industry does when it comes to network automation. More and more people use nornir and where supported napalm and i see at this point no way to interact sanely with mikrotik if we would want to use these tools.
All that said the ansible path using the API is in many terms suboptimal and for sure inferiour to a `config replace` as you described it.
As the nornir path doesn't cope well with Mikrotik we found a okish path with ansible - you might want to check out: https://github.com/narrowin/ansible-mikrotik/ - its our opensource repo. At this point we support L2 devices with mlag building also support for l3 at the time being.Also the ":export" today isn't really the whole "config" (e.g. no container, certificates, etc.). Additionally it could persist sensitive password in plain text, so not ideal for recurring use as a whole
If we disagree, it might be over whether we think that the current state of affairs is acceptable in terms of network automation. Without transactions and upsert, RouterOS will never be able to be automated in a declarative fashion without a huge amount of middleware. If, for example, you look at the Mikrotik community Ansible module: the authors didn't go to the effort of trying to make the module idempotent. It only executes commands as plays. Presumably they stuck to this because doing more would require writing all of the missing middleware to "query the database" with ROS syntax, calculate all of the adds/sets/removes, perform all of them, check to make sure there were no errors, and if there were, calculate the inverse of the adds/sets/removes to set everything back.
The way I see it is that the most people will benefit if Mikrotik is the one that implements the transaction and upsert logic. That way it will be a first-party feature of RouterOS and we (network operators) each won't have to reinvent the wheel in our own development pipelines. I suspect it could also have a marketing and sales impact for selling Mikrotik devices into organizations that are moving towards an automated configuration lifecycle with contemporary tooling (Ansible, Jinja2, etc).
All that said the ansible path using the API is in many terms suboptimal and for sure inferiour to a `config replace` as you described it.
Statistics: Posted by mischa01101 — Sat Mar 29, 2025 1:08 pm