Translated from Mikrotikish, Beta means pre-alpha, RC means early Beta, stable means RC, rinse and repeat on a newer version, now you know. (if it ain't broken, don't fix it).
I feel your pain, but unfortunately it is what it is, before changing version on a complex, multi-layered network there is the need of testing everything in all possible ways (+1).
Actually I am very grateful to people like you that have the guts to apply these new "stable" release to production devices and report their experience, and you just confirmed that devices without a console access should not be used in complex networks.
Yes, they should add a specialized field type in Winbox4 to enter information into this kind of address field!
That should also give capability to select IPv4/IPv6 when entering a DNS name, to resolve and replace DNS name by IP address on the Winbox host system or not, and of course to select interface and VRF from a list.
The current version of this corollary assumes only one step out of phase between one stage and another (Stable means RC).
I would like to suggest that this starts with 3 steps (Stable Means Alpha) that gradually reduce to a single step (as is the current corollary), one step at a time every 3 full trading days.
Therefore, 9 trading days (almost two consecutive weeks) are needed for a Stable to be considered an RC.
Rushed releases are always where the most serious failures occur.
So I don't mind dropdowns or no dropdowns too much.
Speaking of CLI, a [tab][tab] to suggest possibilities or auto-complete interfaces after a % or VRF after an @ would be very welcome.
And from the point of view of WinBox 3 or 4 or web... A small Wizard button that would open a small new screen just to help select interfaces and VRFs would also be interesting.
This is why I already proposed several times: rename channel stable to current. It is just semantics, it would not change anything in regards of release quality/stability. But at least it would stop people complaining that "stable is not stable".
I believe excluded wednesdays, that don't count, and fridays, as no real activity is done on them.
I like your approach , but I would extend the delay between stages to one full working week, or easier, 7 consecutive days (releases around Christmas or the first few days of May will be more problematic, so - even if they are exceptions - it is logical to have a 4 weeks - 28 days - full cycle to be on the safe side).
I need to think about these possible new definitions, now that there is also the long-term version coming into play.
Same here on CAP ax. After rebooting, you have a 10s window to access the device until the capsman data is processed.
It seems to be an issue with the provisioning of 5ghz, since only activating the 2.4ghz config in capsman does not create any problems with this device.
Between RC and 7.22, not only the text label changed...
So they are NOT the same version, and you have NOT tested it on that case.
Since no one can guarantee that you actually really tested something or are lying,
the only thing that is certain is that you installed the version (who cares about the name) that was just released.
You may have done whatever you wanted, but you still installed a version that was released just five full days ago, then you tested it on other devices, and even prepared the upgrade CONTEMPORARY (mass upgrade),
instead of one at a time, with the spare part already ready with the version that works, maybe a week apart before each upgrade.
It's nice of you to call me a Monday expert.
Better Monday experts than "Friday the 13th" (literally) experts...
Ok mate, well, I did say that as well as labbing, we also had this version installed on other switches and routers, live within the network prior to this disaster. It’s becoming clear to me that rextended probably likes rextended a bit, so I’ll move on to folks that might try to add some value.
I do not that stable is the default option when you provision and update a new switch so all this talk about stable not being stable is moot. It’s the default.
Does anyone have any ideas about possible ways to access said unresponsive switch without mac-telnet or ssh? Yes I can send the customers tech out there for a console session again but I’d prefer not.
Users, replying to your initial plea for help / rant ..., were trying to help you to avoid similar problems in the future. If you don't agree with suggestion then do whatever you want ... but don't dismiss the advice just because you don't like it (and because MT official naming is "stable").
As to help to fix the acute problems you have ... well, we don't seem to know what exactly goes wrong in cases like yours (because they are not happening very often) so you'll have to be more patient while waiting for an usable advice. Or you can go above and beyond to analyze state of one of your "hung" devices and see if you can come up with a good advice (to others who might run into same problem as you have).
Stable in software release names means “no functionality is being added, only fixes for inadvertently introduced bugs”. It does NOT mean “this version runs without problems, it will not crash, etc”. It refers to stability in the release cycle, not in the functioning. That is why “stable” is better not used as a label, it causes misunderstanding and dissatisfaction. Much like the label “free”.
Since the devices are not accessible remotely, if one wants to get a better picture of what is going on (to be able to possibly avoid it in the future), they connect a serial console to see what the device is doing while not accessible. What logs there are, what possible output messages there are on the console etc.
Without any logs or any other information from the device itself, what anyone can say? It could be a bug, it could be some combination of configuration causing this, it could be how the stars aligned during the weekend. Who knows?
I updated a plethora of (non critical) devices of multiple architectures and age during the weekend and had no problem whatsoever with v7.22.
And I’ve upgraded both v6 and v7 in the past that caused boot loops or complete crashes, while no one else had the same issue at the time.
So it depends on factors we are not fully aware of. My guess is it depends on how “abused” the ROS installation has been over the years (in terms of configs, reconfigs, changes, upgrades etc etc).
, but I would extend the delay between stages to one full working week, or easier, 7 consecutive days (releases around Christmas or the first few days of May will be more problematic, so - even if they are exceptions - it is logical to have a 4 weeks - 28 days - full cycle to be on the safe side).
