On 3 February 2016 at 15:29, Mikael Abrahamsson <[email protected]> wrote: > I have spent a non-trivial amount of time going through SMUs and testing > upgrades. Considering that Cisco do not do testing of SMUs in any-to-any > configuration, I am a big proponent of SPs, where the SP is properly tested, > and contains all rollup bug fixes.
+1, of course this essentially kills whole concept of in-service upgrades, but they were never really true anyhow. IMHO whole SMU issue is incorrectly presented, users are given impression that there is single IOS-XR release and then there are SMU's which solve exactly one DDTS. Which, if possible, would be terrific. But alas, that's not what SMUs are, they are really just newer version (I'm guessing usually HEAD of that particular branch) of given binary. So I think it would be healthier to present this without abstraction. Say that this bug affects BGP component and you'll need BGP version K or newer to solve it. It is really what it is doing already, just presented as something else. If it were presented like this, then it would be trivial to determine if it's service impacting or not, of course restarting BGP is service impacting. It would also be obvious that BGP version K+7 supersedes K+6 and older. Now as it's presented as magic sauce, determining these trivial issues is complicated. Is the magic sauce possible, even in theory? Could you really solve 1 single issue, in running system and control arbitrary combination of fixes? Choosing another language than C would allow solving 1 single issue run time, like in erlang/BEAM you could rewrite run time single broken function to newer version. But even in that case, could you possible manage arbitrary set of these? You probably could not, but would it even be needed? If you can rewrite the function run-time, then you can force linear progression so if you want given fix on function Z, you also must walk all the earlier changes in order until you're at that fix. -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
