Replies: 2 comments 2 replies
-
That's an interesting idea. Considering one could configure a Cumulus device either way (using FRR vtysh even after it's been configured with nclu) I don't think it makes sense to create a separate device. After all, the initial configuration is done behind the scenes, so as long as it works nobody cares how it's done. There's just one tiny problem: today I could reuse the FRR config for Cumulus VX (or vice versa). There are two distinct files for every configuration module, but once I have something running on one platform I can mostly copy it over. With the nclu approach they would diverge. As long as we're not adding new functionality to Cumulus VX it doesn't matter, but if I decide to implement new stuff (VRFs and VLANs come to mind), then it might not appear on Cumulus unless someone else does the job -- I'm too old to learn yet another CLI ;) To recap: if you feel like doing all the heavy lifting to reimplement existing functionality in nclu go for it and use existing templates. Thank you! |
Beta Was this translation helpful? Give feedback.
-
Implemented a long time ago in cumulus_nvue device (still not sure whether that was a good decision though) |
Beta Was this translation helpful? Give feedback.
-
I was thinking it could be useful to have the Cumulus config in the Cumulus' "nclu style" (basically a list of "net something" commands - and the related commands to fetch the current config).
I am in doubt if to open a PR to patch the current templates, or to create a new config "model" called cumulus-nclu (or something like that).
Which approach would you prefer?
Beta Was this translation helpful? Give feedback.
All reactions