Disaggregation and interface names #1596
-
|
With disaggregated network equipment (ie, ONIE based systems) interface names can show up in the OS with different names, depending on which OS is running on the system. Example: Dell's S4148T device-type in the repo is created based on, I think, Dell's OS10, but if you're running Cumulus Linux on them, they show up with different names (swp[1-48]). Do we have a good way to handle these differences? The only thing I can think of would be to create "duplicate" device-types for the various OSes that can be run on these disaggregated hardware systems. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 8 replies
-
Essentially, you are going to have to duplicate the device types. I would put it under a manufacturer of "Cumulus" and then you can still use the "Dell S4148T" as the device name, but the manufacturer is "Cumulus" instead of "Dell" |
Beta Was this translation helpful? Give feedback.
-
|
Hey @jeffmcadams, Dan is correct. For you, the best way to handle this is probably by duplicating the definitions. That being said, this repository is suppose to act as a source of truth. As products are updated we do our best to update the definition files but largely rely on the community for assistance with that. I don't think we will be adding the duplicates you are speaking of though, sorry about that! |
Beta Was this translation helpful? Give feedback.
-
|
That is unfortunate to hear. You say that the repository is supposed to act "as a source of truth", but there is no single, global, source of truth in this case. There can be/is for the type of interface, but there can be no single, global source of truth for the interface name as that is dependent on which OS is running on the device. How is it determined which OS to use for which device and module type when listing the interface names? |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I wasn't exactly clear on what I meant, as an updated source of truth repository we aim to keep the latest information. For instance, if the latest version of a specific Cisco switch refers to an interface as That all being said, I do like the idea of having a versioning feature. Unfortunately this repository immediately inherits its guidelines from the upstream NetBox repository. This means that if something is included upstream, we implement it here. If it is not in the upstream repository, then we cannot implement it here. In that case, we recommend posting a discussion or FR in the NetBox repository and once it is implemented and live we can include it here. As a preliminary thought, I have the idea that maybe device types can have an OS version selector. This selector would then change the device type template based upon that version. Then we could include in here a new tag, i.e. Lastly, I just want to clarify something. Most of the people who work on this repository direction, myself included, are volunteers who provide our best efforts to maintain it. We rely highly on the community to contribute changes/additions when they are warranted. We listen to the community and try to enforce a structure that is agreed upon by the majority. As I explained earlier, if you want to propose a change you are more than welcome to, and the more support you garner the better change you have at it becoming a reality. |
Beta Was this translation helpful? Give feedback.
-
I think the big disconnect here is that while you can install whatever you want on these switches, the "base" install, which is what we really want to capture here, for the Dell switch, is the Dell OS, not Cumulus. That is why I suggested we create a separate folder "Cumulus" and set the manufacturer for the Dell switches with Cumulus to Cumulus and not Dell, because they stopped being pure Dell the moment you installed Cumulus on it. I would like to get non-maintainer feedback. Honestly, I wish the interfaces could be dynamicially renamed in some cases based on a pattern (for example, Cisco Switches in a stack) but we don't have that capability upstream yet. But something like: {device.platform.naming.10GBE} {device.position} {device.slot} {device.port} would be an absolutely dream, alas, we are not there yet, and we won't likely be for a long while. |
Beta Was this translation helpful? Give feedback.
-
|
Trying to respond to both of you without doing multiple comments, so bear with me. @danner26 I hear what you're saying about staying up to date with the latest version...wholeheartedly support it, but that is not at all what my query was about. I'm not talking about different naming based on different versions of the same OS...I'm talking the large number of network devices (well, and compute servers, to be honest) that can run completely different OSes on them, not just different versions of the same OS. The S4148T that I used as my first example, can run Dell OS10, Cumulus Linux (big ol' asterisk on that one, so maybe not a great example), PicOS, any of a number of flavors of SONiC, and numerous other OSes that I'm personally not familiar with. (For compute servers, the analogous concern would be between Windows, potentially various BSDs, and various distros of Linux, some of which might use predictable interface naming, and some don't). I'm quite happy to work with the volunteer maintainer community, indeed opening this discussion item was the first step of my attempt to do exactly that. I'm looking to make use of the device-type library in our setup as we're beginning our journey of implementing Netbox, and envision that it would include a significant amount of us contributing back changes and updates that we find. Love the idea, and quite happy to work in that world. @DanSheps OK, I kinda get the idea of going with an OS that's original installed and/or supported by the vendor, but even that doesn't get you down to a single, global, source of truth. First off, in the disaggregated switch market, it's strongly envisioned that customers won't necessarily be running the OS developed by the vendor, and more than a few of the vendors don't even have their own (EdgeCore, Accton, Quanta, and more). On the flipside you have some vendors that have more than one of their own OS. Take, for example, the SN2010 by Mellanox (BTW, Mellanox got bought by NVidia...should there be a directory name change there? I don't know how much pain that would cause users of the library), NVidia sells the SN2010, and others of the Spectrum ASIC switch line, with either Cumulus or Onyx OSes. Those are both OSes that are owned, developed by, and natively shipped on Spectrum switches by NVidia, and they use completely different interface naming. Agreed that it'd be nice to be able to dynamically handle this based on the OS version like a platform, and understood that it's a thing that doesn't exist yet in Netbox-land. And we're just starting down our Netbox implementation journey, as mentioned above, and haven't made actual use of the devicetype-library yet, but are very interested in doing so. That means I don't really, yet, understand the practical impacts of how the import system works, but I saw reference to a script that can do selective imports? Perhaps that could be leveraged somehow to select between alternatives? As a potential user, envisioning how I think this would work, I'd be quite happy, when picking a device type to add a device, to pick "S4148T (Cumulus)" rather than "S4148T" or "S4148T (PicOS)" to specify that I'm looking for the Cumulus naming rather than the "default" OS10 naming or PicOS naming. |
Beta Was this translation helpful? Give feedback.
-
|
I think one important thing to remember is the devicetype library is not the be-all-end-all of device types. It is to be a starting point and you import it into your envrionment and then modify it as you see fit for your environment. The script is not required anymore. You simply set the github repository as a datasource and then select "Data File" as the import. You can then select from any of the available YAML files. We can add additional YAML files per model but there should ideally only be one model per YAML otherwise someone will import more then they are barganing for. |
Beta Was this translation helpful? Give feedback.
-
|
While you don't have to use the script, you absolutely can. It still is utilized and works. |
Beta Was this translation helpful? Give feedback.
I think the big disconnect here is that while you can install whatever you want on these switches, the "base" install, which is what we really want to capture here, for the Dell switch, is the Dell OS, not Cumulus. That is why I suggested we create a se…