Think about you resolve to imagine the advertising story of your most well-liked networking vendor and begin utilizing the REST API to configure their units. That most likely entails some funding in automation or orchestration instruments, as no one of their proper thoughts needs to make use of curl or Postman to configure community units.
A number of months later, after your toolchain has been completely examined, you resolve to improve the working system on the community units, and all the things breaks. The foundation trigger: the seller modified their API or the info mannequin between software program releases.
Why Does It Harm So A lot?
There’s nothing extra annoying than having to vary your working code simply because an API (or a knowledge mannequin) your code is utilizing has modified. You waste quite a lot of time simply to maintain issues working whereas gaining completely no additional performance. Within the worst case (in networking), you’re compelled to maintain working with two (or extra) variations of the info mannequin in parallel (and retaining monitor of which model to make use of with which system) as a result of you’ll be able to’t improve all units in a single shot.
Most suppliers of API-based companies are properly conscious of that and do their greatest to maintain their APIs steady. Even Google (the infamous deprecator) modified their analytics API solely as soon as in additional than a decade I used to be utilizing their product. Whereas doing that, they’d a couple of year-long grace interval throughout which each variations of the API labored.
However Networking Is Totally different, Proper?
As at all times, some folks assume that networking needs to be completely different. You may be fortunate and work with a vendor that discovered the exhausting means that prospects want stability, otherwise you may be utilizing a vendor that adjustments their information mannequin yearly, like Nokia does with SR Linux.
You may declare that I’m selecting on Nokia, and I may be. Whereas I really like their work on containerlab and recognize that they make SR Linux out there in a fast-starting, free-to-download container format, there are specific issues no vendor ought to be doing, and breaking guarantees they made to their prospects (a printed API or information mannequin is someplace between a promise and a contract) is fairly excessive on my listing of issues to keep away from.
Of the two dozen platforms netlab helps, solely Nokia SR Linux requires configuration template adjustments with each different software program launch (netlab configuration templates had been impacted by software program releases 25.3, 24.7, and 23.3). Whereas FRRouting loves altering the info constructions of JSON printouts (which completely breaks our validation scripts), I don’t keep in mind ever having to vary a configuration template to accommodate a more recent software program launch from a significant networking vendor (VyOS is one other unlucky exception). On the opposite facet of the spectrum, Cisco IOS launched tackle households in BGP many years in the past, however nonetheless acknowledges the previous IPv4-only configuration syntax.
What’s Altering?
One would perceive that you must break some eggs to make a greater omelet, however some SR Linux adjustments we needed to cope with are so banal that they’re driving me loopy. For instance, in SR Linux launch 25.3:
- They modified the best way you set BGP MED in a routing coverage. Beforehand, the attribute was set with
/routing-policy/coverage/entry/motion/bgp/med/set, now you must set the/routing-policy/coverage/entry/motion/bgp/med/operationto set. Why couldn’t they keep each choices? - Prefix matching in a routing coverage was specified with
/routing-policy/coverage/entry/match/prefix-set, now it’s/routing-policy/coverage/entry/match/prefix/prefix-set. WTA*? - BGP group propagation was specified per BGP neighbor; now it’s set per tackle household. Many distributors belatedly realized (or in no way) that some BGP attribute dealing with ought to be configurable on the AF-level, however most of them retained backward-compatible syntax once they modified their thoughts. For instance, configuring a parameter per neighbor would nonetheless be allowed and affect all tackle households.
I’d have hoped the shopper’s well-being can be valued greater than a puristic view of the info mannequin, however I’m clearly misguided. Alternatively, even Ansible, with its “we minimize it thrice and it’s nonetheless too brief” stunts, mastered the artwork of deprecating performance. I actually can’t grasp why somebody would really feel the urge to abruptly break the info mannequin as an alternative of slowly deprecating previous attributes.
Then there are extra elementary adjustments to the info mannequin. What was a single worth might change into an inventory. For instance, SR Linux 24.7 launched a number of routing insurance policies per BGP neighbor, altering the import-policy and export-policy parameters from strings to lists. Even that’s trivial to unravel – netlab silently converts scalar values to lists as a result of we don’t wish to drive the purchasers to surround stuff in sq. brackets for no good cause. Typical CLI configuration instructions that beforehand accepted a single worth might begin accepting an inventory of values. XML additionally had no issues with the one-or-many dilemma, which could clarify why Junos fortunately takes a single worth or an inventory of values for a lot of configuration parameters.
Nevertheless, you’ll be able to’t see these options should you drank an excessive amount of YANG Kool-Support. YANG is a strongly typed schema language and doesn’t enable a number of information varieties for a single parameter. However even the YANG world has an answer: you’ll be able to specify mutually unique parameters with the alternative assemble. Within the above instance, we might have import-policy taking a single worth and import-policy-list taking an inventory of values.
However like breaking adjustments to the configuration information mannequin wouldn’t be sufficient, there’s extra:
- SR Linux makes use of the identical information mannequin for CLI configuration, which implies that the breaking adjustments within the API/YANG information mannequin additionally break the CLI configuration course of.
- When you save the configuration of a tool working SR Linux launch 24.10 (utilizing
get /from the working datastore), and that configuration makes use of one of many modified information mannequin parameters, you can’t load it on a tool working SR Linux launch 25.3. I’ve by no means seen a community system with out that baseline stage of backward compatibility.
Even assuming one can’t keep away from breaking adjustments, there’s a clear resolution to the entire above: API or information mannequin versioning. The best resolution can be to ask the purchasers to incorporate the goal software program model in each configuration request and do the mandatory translations behind the scenes. Why do you assume Cisco IOS configuration begins with the model command?
What May We Do?
Is there one thing you are able to do about distributors breaking APIs and information fashions (it most likely isn’t simply Nokia – please depart a remark along with your horror story)? Make your self heard. Perhaps you’ll hit a ache level someplace (it labored for me no less than as soon as), or perhaps there’s somebody inside the vendor group who is aware of what must be finished however can’t make the adjustments with out exterior strain.
Lastly, I at all times instructed folks yammering about vendor conduct to vote with their wallets, however that doesn’t appear to work on this case. Nokia should have a very loyal set of shoppers to have the ability to break buyer provisioning instruments simply to retain a clear configuration information mannequin.
