[Feature] Platform/Device Type family grouping #13704
Replies: 3 comments 3 replies
-
|
Before changing the database and requiring maintenance of new record types for everyone, are there other ways to accomplish this, from creating a Custom Report to detect misaligned records to using Custom Validation to prevent misaligned records from being created? There are a number of extension and customization mechanisms, and it is best to try and exhaust their capabilities first, before making the schema and validation more rigid globally
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Omripresent ***@***.***>
Sent: Wednesday, September 6, 2023 12:38 PM
To: netbox-community/netbox ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [netbox-community/netbox] [Feature] Platform/Device Type family grouping (Discussion #13704)
What
The current correlation between a given set of platforms and devices types is only available by the manufacturer field, with different type of hardware platform families and overlapping versions it's hard to keep up with the different associations.
My proposal is to have another model in the hierarchy between the manufacturer and device types/platforms that if used will restrict the associated platforms of a given manufacturer to the associated device types.
Why
For example, F5 Networks has two type of platforms running either the known BigIP/tmos software and the newer F5OS software for its R series devices, there's no built in mechanism to group certain device types and platforms to prevent the assignment of BigIP platform on an R series device.
How
This change would likely require the following database changes, an additional model under DCIM will be required as well as additional fields in the manufacturer, device type, and platform models.
________________________________
I would like to have input from other users before submitting the feature request to account for other user cases.
—
Reply to this email directly, view it on GitHub<#13704>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM6RAKS7QHW2D3CXPSLXZCYKDANCNFSM6AAAAAA4NWBTAA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I was seeing this as a more optional addition giving the ability to scope out platform assignments similar to how VLAN group scopes work today. That won't force anyone to use this capability same as there's no enforcement to assign VLANs to groups or force group scope assignments today. The main ask is to provide a built in capability that will allow UI/API enforcement per each user's needs. |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if it would also be useful to have the platform associated with device-type, so you could set it once and have it auto-populate if it were set. Setting platform in device type doesn't make sense for server hardware but it does for network hardware. You could create a custom object field on device type to reference platform and a script or report to audit/remediate the device records for compliance
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Omripresent ***@***.***>
Sent: Friday, September 8, 2023 7:04 AM
To: netbox-community/netbox ***@***.***>
Cc: Mark Tinberg ***@***.***>; Comment ***@***.***>
Subject: Re: [netbox-community/netbox] [Feature] Platform/Device Type family grouping (Discussion #13704)
I was seeing this as a more optional addition giving the ability to scope out platform assignments similar to how VLAN group scopes work today. That won't force anyone to use this capability same as there's no enforcement to assign VLANs to groups or force group scope assignments today. The main ask is to provide a built in capability that will allow UI/API enforcement per each user's needs.
—
Reply to this email directly, view it on GitHub<#13704 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM2RFICZ27HB3IVAQ63XZMCT5ANCNFSM6AAAAAA4NWBTAA>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
That wouldn't work for our specific use case, some code gets certified for certain roles in our network for the same device type so binding the platform to a specific device type wouldn't work for us. We could implement as suggested with custom fields and scripts to remediate any inconsistencies but it would still allow for user error at input, We use Netbox to drive our provisioning process and a device could ZTP with the wrong platform causing a whole set of other issues, so enforcing this retroactively doesn't fit in our case. Even with a custom plugin it won't give us the capability to update the new/edit device view to support the UI filtering in the user input. |
Beta Was this translation helpful? Give feedback.
-
|
then how about custom validators, are they rich enough to cover this case? or putting the logic in your provisioning custom Scripts? so people aren't using an unfiltered +New Device workflow to add records, but one where you can limit the fields, options and provide your own validation code. There are just so many built-in integration points that I think a lot of customization cases can be solved with the creative application of what already exists.
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Omripresent ***@***.***>
Sent: Friday, September 8, 2023 10:00 AM
To: netbox-community/netbox ***@***.***>
Cc: Mark Tinberg ***@***.***>; Comment ***@***.***>
Subject: Re: [netbox-community/netbox] [Feature] Platform/Device Type family grouping (Discussion #13704)
That wouldn't work for our specific use case, some code gets certified for certain roles in our network for the same device type so binding the platform to a specific device type wouldn't work for us. We could implement as suggested with custom fields and scripts to remediate any inconsistencies but it would still allow for user error at input, We use Netbox to drive our provisioning process and a device could ZTP with the wrong platform causing a whole set of other issues, so enforcing this retroactively doesn't fit in our case.
Even with a custom plugin it won't give us the capability to update the new/edit device view to support the UI filtering in the user input.
—
Reply to this email directly, view it on GitHub<#13704 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM2IXAEHGTAJUNS27FDXZMXKHANCNFSM6AAAAAA4NWBTAA>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
We already had some of the logic in custom scripts but some of those blew up after the 3.5 change to how custom scripts were managed so I'm not too excited about using those, especially where anyone can still access the native views and create new devices. I've already considered a few ways of implementation but to me it seems that a native implementation makes the most sense. We rely on scripts and custom fields for a lot of other use cases. |
Beta Was this translation helpful? Give feedback.
-
What
The current correlation between a given set of platforms and devices types is only available by the manufacturer field, with different type of hardware platform families and overlapping versions it's hard to keep up with the different associations.
My proposal is to have another model in the hierarchy between the manufacturer and device types/platforms that if used will restrict the associated platforms of a given manufacturer to the associated device types.
Why
For example, F5 Networks has two type of platforms running either the known BigIP/tmos software and the newer F5OS software for its R series devices, there's no built in mechanism to group certain device types and platforms to prevent the assignment of BigIP platform on an R series device.
How
This change would likely require the following database changes, an additional model under DCIM will be required as well as additional fields in the manufacturer, device type, and platform models.
I would like to have input from other users before submitting the feature request to account for other user cases.
Beta Was this translation helpful? Give feedback.
All reactions