High level:
An update to The Dude server+client would be a great first step…
Big Lebowski is right: “That rug really tied the room together.”
Rational: All the underpinnings for a “controller” are already in the Dude server. And y’all’s native multiplatform client for WinBox4 seems to be a BIG HIT, so Dude2 make a lot of sense to me. And, in world of HTML UI for these things… some native client to “control the controller” be a novel approach (and like more responsive/rich and more easily extended). And, most importantly, allow rich Layer2 support for discovery (CDP/MDP/LLDP/RoMON/etc) which are hard from a web GUI.
So…specific answers below assume some “new Dude” (aka Dude2) approach – since I’m already using The Dude package+client as a “controller” today - with only some minor grips over years. And that’s what I’m really looking for — even if it was just a client that was a “copy” of the existing Dude client with NO new features 
- Are you interested in a central controller for MikroTik devices? If yes:
a) do you need it for wireless settings only (like a centralised capsman)
b) or you are interested to manage all configuration of these MikroTik devices
Any RouterOS device — Wi-Fi should not be special.
CAPsMAN is flexible enough for Wi-Fi config. But it should NOT do the RouterOS system config stuff it does today – just push Wi-Fi params. The “new controller” should deal with all system level stuff like config/upgrade/initial setup - not CAPsMAN - but it should be able to set a “device” as a CAPsMAN server, but CAPsMAN config be applied same as any other RouterOS config in this theoretical new controller.
- How would you like to run it?
a) “Cloud solution” hosted by MikroTik?
b) Self hosted server on X86 (*NIX)
b) Self hosted server as package on a powerful MikroTik router
A RouterOS .NPK package for the “server” — y’all have CHR for larger use cases to run the “new controller” NPK (i.e., dude2.npk ;)). And native WinBox4-like version of The Dude client to manage it.
Why mess around with testing/packaging to deal with some arbitrary OS environment? Not mention how to “monitor the monitoring server/software”… now requires more stuff on running non-RouterOS device to do that… contra., in the old Dude server, you could solve this easily running a 2nd dude to handle “monitoring the monitoring”.
While I don’t use Docker/Kubernetes/etc for these things, but a lot folks do. But perhaps documenting/supporting CHR under “Docker” be easier to cover the “docker” needs. In fact CHR can already runs under Docker.
- What features would you like to see mostly? (mass auto-upgrade, configuration, provisioning, monitoring)? Please provide as much detail as possible.
All the features of current The Dude server package, plus:
- CLI for anything possible in the current Dude client…
- Specifically, being able to exporting data as CSV and SVG from RouterOS CLI and/or web service from the SQLite the Dude uses
- Direct support for RoMON as a transport and discovery mechanism within Dude.
- ability to dynamic render maps, or other views, via HTML – for a dashboard (outside of webfig, so renderable as a view for NOC or customers)
- have some “friendly name” for a device, which may include client devices on LANs
For upgrades, being able to “assign” a version on a Dude tracked router device - applied with via Dude2 client, or via CLI + /system/scheduler can be used to cause/check upgrades as desired within the controller (aka Dude2).
Now, for configuration, the existing Dude is lacking there… I’d like to see some complete configuration to be stored with a RouterOS device in Dude, ideally in some templated form to allow variable substitution. It be fine if config is applied as a whole similar to TR069 just simplier/built in to controller (i.e. require a reboot to be applied). While a richer configuration scheme be nice, that seems like it could a “version 2” thing once the basic of new controller is figured out.
Additionally, adding some “update” as RouterOS primitive config command (with some guid=xxxx…xxxx to identify it) that either adds OR updates any existing entry - that would go a long way to be able to create some “templated config” – today re-apply config is not an easy task… The current “set”/“add” scheme gets in the way of “applying a config” over an existing config. And why I suggest a “whole” config a la TR069 that get applied be better than nothing for remote provisioning of routers.
- How do you imagine this service would look? Similar to current CAPsMAN, based in RouterOS configuration, or something completely new, moden web based UI etc.
For “client” or the UI side of the controller… instead HTML-based UI as the controller, a multiplatform client is what should work any OS (not the controller server). The WinBox4 framework applied to whatever controller be a nifty approach. And a native client is easier to L2-type discovery, to avoid IP stuff being need for setup/flashing/adopting/etc type stuff.
While, there should be some HTML/web server support — HTML should be limited for “dashboards” – with those dashboard defined in the purposed Dude2 multi-platform client, kinda like “skins”, but for status. Or more sophisticated “HTML components”/widgets that can be rendered in existing web pages as desired. But HTML5 for configuration seems like a backward step - especially with all the great work that’s gone into WinBox4 which likely could be partially reusable for a Dude2.
And to increase “easy-of-use”…
- some config wizards in the client to create a config (and have that generated+templated config “assigned” to a device).
- capturing more use cases as a “QuickSet profile” for more advanced configurations like multi-wan, VPN gateway, etc.
& these could be used as the config to “assign” to a device in the Dude2 controller.
