If it is the devices controller this could explain why version 7.9beta takes that long to be prepared.
I thought it was BFD reaching out to say hello. But Iâm pretty sure weâll both be disappointed.
might be CAP AX (XL)
I think eduplantâs point here is the most important one here. Iâm just elaborating below, so please consider their comment. 
Without configuration transactions any tool is just another way to mutate state on a device: It doesnât matter if itâs a single pane of glass for twiddling 1000 devices, itâs still going to be a process of: read, observe, decide, then write back regardless of the transport method or whether a human or computer is doing it. A multi-device config interface allows you to make changes faster but doesnât help determining what changes to make.
Transaction support is the clearest pathway to declarative configuration and the software/IT/tech world is rapidly moving to declarative configuration and infrastructure-as-code.
While it currently appears that thereâs Ansible support for RouterOS, a closer examination shows itâs parsing and wrapping the CLI just like a human. Any idempotent behavior with Ansible must be hand-coded by the user in the Ansible script. Writing repeatable deploys or config update requires a lot of RouterOS scripting e.g. [find where ...] and the work and testing associated with that is much more work than specifying the actual desired configuration. Wrangling repeatable router setup is extremely difficult to achieve without writing a ton of defensive scripting code. Any of this logic will need to exist somewhere in a mass-config tool unless itâs moved elsewhere.
The idea for MikroTik to keep their offering vendor-neutral makes a lot of sense, and adding config transactions allows MikroTik devs and communities of things like Ansible, Terraform, and scriptwriters be more productive in a way only MikroTik can deliver by adding a transaction abstraction to RouterOS.
+100 for that would be a killer upgrade (checkpoint, VyOS, barracuda,⌠all those vendors have something alike for years now)
integration or a solution like that would enhance large/mass deployments big time!
You know about the { command; command; command; } construct from commandline?
The issue is definition of a âfailed operationâ is tricky, with or without transactions. So the { command, ⌠} will protect against bad syntax, and that may help in a lot of cases. But everyoneâs definition of what failure looks like beyond that may be different. So âtransactionsâ arenât the whole story. From a SQL POV, you need a schema to enforce transactional integrity too. And not sure that part be so easily express by the admin (e.g. in the using Ansible etc. track), which look a lot more like policy config, than directly help with controlling devices.
While configâs structure is very âSQL-ishâ, and thatâs a good thing, Iâm not sure that means the API and wire protocols need to follow SQL off a cliff.
Perhaps a model of a âtemplate-configurationâ thatâs âappliedâ to devices. Unlike default-configuration, this template offer âtemplate parametersâ that can be dynamically changed by âcontrollerâ at runtime. And thatâs not far off whatâs done today, except be âdynamicâ and avoid either monolithic config replace/reboot or complex :if/set/add syntax thatâs âpushedâ (and thus managed) by a âcontrollerâ. Basically a âidempotent QuickSetâ, with parameters provided by the âcontrollerâ and the QuickSet profiles customizable is closer to whatâs be looking for than âtransactionsâ. Especially for the ansible, terraform, etc. âplaybookâ cases â if this API-controlled QuickSet got bad data or otherwise failed, then it reports the failure (and cleans up itself) â no âtransactionsâ required, it only one.
But I ainât picky, the issue is how to best describe the desired idempotency for the controlled device and thatâs whatâs key⌠the mechanism less so.
It is not clear to me what people want and expect⌠the { command; command; command; } construct already makes sure that only the complete set of grouped commands is processed, and then there is the âsafe modeâ that can roll back changes when they result in loss of connectivity.
It is already so much better than what I know from e.g. Cisco IOS (but that is some time ago).
Sometimes it is nice to have the model of âapply config, run a test, and if test fails revert to previous configâ (as seen in Ubiquiti devices, for example) but it is often difficult to test well within the short interval available for that so it usually is only a test for connectivity, which we already have. Except for the case where you e.g. change the config of a VPN and a disconnect/reconnect is fully expected, in which case safe mode cannot be used.
If only it did work that way, it would save so much pain when trying to bring a replacement unit up. I took me 2 hours of mucking around ti massage my RB750gr3 config into my RB3011, manually extracting certificates and importing them prior to loading config back in for VPN to avoid config errors. also the ability for routeros to ignore duplicate config rather than erroring out.
Maybe its just that people know how to slice and dice a config file to get it to import correctly but the output that an export generates almost never goes back into a device without re-jigging the config, having config dependencies defined before the config that it depends on would be a huge plus, even if there was a way to tell export to format a config in a way where it could be loaded into a new device.
Maybe that is what a Device controller can do. apply a device config to a different kind of device and give you an opportunity to map specific ports to new ports on the different hardware.
Not a problem wholesomely unique to Mikrotik either, Cisco are just as bad with differences between hardware and software platforms (NXOS, IOS, IOS XE etc)
Agree! The config export file should:
- include ALL configuration, at least optionally. also the users and certificates.
- have a facility to import the export file in a load-and-replace fashion, i.e. a combination of âclear configâ and âimport fileâ, with continuation on non-fatal errors.
As it is now, loading of a config file is an expert job.
Already on post #32, this topic is one useless frill⌠10 months and no news, no comment, no something from Staff involved of development of somethingâŚ
http://forum.mikrotik.com/t/mikrotik-devices-controller/158354/1
I think they have forgotten about it haha
Very ashame..
It MUST be able to monitor and auto discover devices with IP addresses that are assigned dynamically (I.e DHCP or IP pool if dialing in via VPN). The auto discover needs to be smart enough to not add a new device when device already exists but IP has changed.
Also an option to auto discover the device with the router identity as the display name.
You didnât see that in the beta version of the controller? 
I think it already does all those device discovery thingsâŚ
I did not know about this construct. I appreciate the comment 
Now that I think about it, if some of the final or interstitial commands are written as tests for previous commands that error out if something doesnât add up. I could see doing pings, arp, fetch, resolve etc. in tests like that. I guess the issue is that itâs just a lot of code to write, test, and debug. On the other hand, I canât think of what I reasonable default idea of a transaction failure would be, so perhaps the way it currently is is the most reasonable and I just need to get more comfortable with scripting and testing.
I guess I just donât have that much experience looking at real-world code where semi-high-stakes changes are made. I do small community ISP work and we just havenât gotten to the point of needing to edit devices where a lot of users are using it and success is critical.
Any news about mikrotik device Controller?
Hi all,
because of MT inability to release anything after 1 yearâŚcheck UPTIME MONITOR. It is opensource and it can run in docker. It can send you notofication thorough many providers etc Microsoft teams and it is very simple, nice monitoring of servers.
Pretty âsimpleâ I think to develop a good controller:
Step 1: Fix your DNS Implementations, make stuff like mDNS great again!
Step 2: Update / fix your Openflow Integration
Step 3: Fix your [âŚ] implementations
Step 4: Make Controller that supports Openflow asides just Mikrotik devices
but for the love of god start at Step 1 before you attempt anything else at all!
That is just a NMS. not a controller.
Iâm using Cloutik.com but since I learned about Omada and experienced to many disappointments on Mikrotik LTE devices I have to switch to Omada - how it look and work is perfect.
Mikrotik, is there any chance soon?