Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support dynamic definition of powerport and interface types #838

Open
glennmatthews opened this issue Aug 20, 2021 · 4 comments
Open

Support dynamic definition of powerport and interface types #838

glennmatthews opened this issue Aug 20, 2021 · 4 comments
Labels
type: feature Introduction of new or enhanced functionality to the application

Comments

@glennmatthews
Copy link
Contributor

User Stories

1

As Nelly the Network Engineer,

I want to be able to accurately represent the hardware present in my network, including any number of newly introduced power port types and interface types,

So that my source of truth provides as much detailed and accurate information as possible.

I will know this is done when I can add new hardware to Nautobot without needing to wait for a new release of Nautobot to support this hardware definition.

2

As Cora the Coder,

I want to get out of the business of needing to write new Nautobot code (even if only a few lines) every time a hardware manufacturer or standards body develops a new interface hardware type or power port connector type,

So that I can focus my time and development effort on other Nautobot features and fixes.

I will know this is done when I no longer need to release a new version of Nautobot to support a new interface hardware type or power port connector type.

Database Changes (Optional)

This would follow a similar model to the customizable Status model, wherein we replaced a hard-coded list of supported values with a new database model. Probably we will need one model for InterfaceType and another model for PowerPortType.

We'll need to be cautious about how we migrate existing data to use the new model, as the way that we autogenerate Status values at install time has occasionally been problematic with regard to testing and reuse of test databases.

External Dependencies (Optional)

We'll need to think about how to retain compatibility with https://github.com/netbox-community/devicetype-library as it would be a shame to lose the ability to import hardware types from that repository.

@glennmatthews glennmatthews added the type: feature Introduction of new or enhanced functionality to the application label Aug 20, 2021
@pozar
Copy link

pozar commented Aug 23, 2021

I would give an upvote to this concept. If we can abstract the interface and data type being passed over this interface, nautobot would be much more flexible to progress made in networking and also could expand into other areas such as media interfaces. Right now we have different groups of interfaces such as Ethernet, Serial, SONNET, Wireless. I would love to be able to add "Media" with interfaces like XLR, BNC, RCA Pin Plug, 1/4" TRS, etc. This would open up other applications and markets.

@aaashok1225
Copy link

aaashok1225 commented Sep 1, 2021

We also require this feature to define a custom interface group because the current nautobot version has LAG grouping for physical interfaces but we need to group virtual interfaces also where SD-WAN is being used which is not supporting in the current version.

@nniehoff
Copy link
Contributor

I wonder if this would also apply to things like cable types as well or should that be an additional feature request

@glennmatthews
Copy link
Contributor Author

Sure, it would be a good idea to review all of the static lists in nautobot/dcim/choices.py and see which of the following would make sense to make extensible:

  • ConsolePortTypeChoices
  • PowerPortTypeChoices
  • PowerOutletTypeChoices
  • InterfaceTypeChoices
  • PortTypeChoices
  • CableTypeChoices

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature Introduction of new or enhanced functionality to the application
Projects
No open projects
Status: To Groom
Development

No branches or pull requests

5 participants