starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add sub-category under Platforms to track firmware version #4216

New Issue
Closed
opened 2025-12-29 18:33:55 +01:00 by adam · 9 comments
adam commented 2025-12-29 18:33:55 +01:00
Owner
Copy Link

Originally created by @ledgley on GitHub (Oct 26, 2020).

Environment

  • Python version: 3.6.8
  • NetBox version: Any

Proposed Functionality

Addition of a sub-category under Platform that would allow the addition of a firmware/software version.
Example:
Platform: NXOS
Version: 7.0(3)I7(8)

Use Case

Within out NetBox environment we require more granular tracking of software version for various use cases such as software lifecycle, vulnerability management and version specific config contexts. We currently use the Platform model to track specific versions, rather the intended use of tracking the actual platform (ie. NXOS). We would like, for example, to be able to apply a config context to either a Platform or a version or subset of versions. Similarly it is useful to have visibility where devices are not running the 'approved' version of a specific platform.

Database Changes

At least one new field in dcim.platform would be required to track the 'version'.

External Dependencies

None.

Originally created by @ledgley on GitHub (Oct 26, 2020). ### Environment * Python version: 3.6.8 * NetBox version: Any ### Proposed Functionality Addition of a sub-category under Platform that would allow the addition of a firmware/software version. Example: Platform: NXOS Version: 7.0(3)I7(8) ### Use Case Within out NetBox environment we require more granular tracking of software version for various use cases such as software lifecycle, vulnerability management and version specific config contexts. We currently use the Platform model to track specific versions, rather the intended use of tracking the actual platform (ie. NXOS). We would like, for example, to be able to apply a config context to either a Platform or a version or subset of versions. Similarly it is useful to have visibility where devices are not running the 'approved' version of a specific platform. ### Database Changes At least one new field in dcim.platform would be required to track the 'version'. ### External Dependencies None.
adam added the type: feature label 2025-12-29 18:33:55 +01:00
adam closed this issue 2025-12-29 18:33:55 +01:00
adam commented 2025-12-29 18:33:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 29, 2020):

Addition of a sub-category under Platform that would allow the addition of a firmware/software version.

What is the intended benefit here versus simply storing the version number as part of the name?

@jeremystretch commented on GitHub (Oct 29, 2020): > Addition of a sub-category under Platform that would allow the addition of a firmware/software version. What is the intended benefit here versus simply storing the version number as part of the name?
adam commented 2025-12-29 18:33:55 +01:00
Author
Owner
Copy Link

@ledgley commented on GitHub (Oct 29, 2020):

I take your point, though essentially I see providing a parent/child relationship similar to Tenant Parent/Child as an option to provide more granularity in how Config Contexts can be applied to devices and groups of devices.

Parent/Child relationship will enable us to more easily apply Config Contexts to, for example, all IOS devices OR a subset of IOS versions.

To answer your question specifically, storing version numbers as part of the name eg. IOS-x.y.x inhibits the ability to take the above approach as it would result in one or the other when applying Config Contexts.

@ledgley commented on GitHub (Oct 29, 2020): I take your point, though essentially I see providing a parent/child relationship similar to Tenant Parent/Child as an option to provide more granularity in how Config Contexts can be applied to devices and groups of devices. Parent/Child relationship will enable us to more easily apply Config Contexts to, for example, all IOS devices OR a subset of IOS versions. To answer your question specifically, storing version numbers as part of the name eg. IOS-x.y.x inhibits the ability to take the above approach as it would result in one or the other when applying Config Contexts.
adam commented 2025-12-29 18:33:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 30, 2020):

providing a parent/child relationship similar to Tenant Parent/Child as an option to provide more granularity in how Config Contexts can be applied to devices and groups of devices

That's not what was proposed, though. The original issue states

At least one new field in dcim.platform would be required to track the 'version'.

It's not clear whether you're proposing adding a new field, or a new model, or something else. Could you please elaborate on what specific changes you are proposing?

@jeremystretch commented on GitHub (Oct 30, 2020): > providing a parent/child relationship similar to Tenant Parent/Child as an option to provide more granularity in how Config Contexts can be applied to devices and groups of devices That's not what was proposed, though. The original issue states > At least one new field in dcim.platform would be required to track the 'version'. It's not clear whether you're proposing adding a new field, or a new model, or something else. Could you please elaborate on what _specific_ changes you are proposing?
adam commented 2025-12-29 18:33:56 +01:00
Author
Owner
Copy Link

@ledgley commented on GitHub (Oct 30, 2020):

This is a feature request. I am new to Django and I am not a developer. I am simply trying to put forward a use case that is not currently met. I can appreciate you would like a narrow description, though I lack the expertise to provide this.

My requirement is that I can parent a 'firmware version' to a 'platform' ie. 7.0(3)I7(8) belongs to NXOS.

This allows me apply a Config Context to either NXOS or 7.0(3)I7(8). Applying to the 'parent' should encompass all 'child' elements.

@ledgley commented on GitHub (Oct 30, 2020): This is a _feature_ request. I am new to Django and I am not a developer. I am simply trying to put forward a use case that is not currently met. I can appreciate you would like a narrow description, though I lack the expertise to provide this. My requirement is that I can parent a 'firmware version' to a 'platform' ie. 7.0(3)I7(8) belongs to NXOS. This allows me apply a Config Context to either NXOS or 7.0(3)I7(8). Applying to the 'parent' should encompass all 'child' elements.
adam commented 2025-12-29 18:33:56 +01:00
Author
Owner
Copy Link

@ledgley commented on GitHub (Nov 27, 2020):

@jeremystretch How can I help progress this feature request? I believe the information provided is clear, given there are 👍 's indicating support. Is there information that I have not provided or is unclear?

@ledgley commented on GitHub (Nov 27, 2020): @jeremystretch How can I help progress this feature request? I believe the information provided is clear, given there are 👍 's indicating support. Is there information that I have not provided or is unclear?
adam commented 2025-12-29 18:33:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 30, 2020):

I believe the information provided is clear

Per my previous comment, it is not. You've shared a vague summary of functionality, but have provided no details concerning its proposed implementation. As an open source project, NetBox relies on its user base to help propose, craft, and implement new features. Please spend more time thinking about what your proposed change looks like and write up a detailed proposal. (There are plenty of other feature requests you can use for inspiration.) Here's a non-exhaustive list of key topics to get you started:

  • What specific problem or limitation are you addressing?
  • What change(s) do you want to make to the data model?
  • What existing functionality might this break?
  • What is the estimated performance impact?
  • How will current users adopt to the new model?
  • How will filtering work?
  • How is this change be represented in the REST API?

Please update your original post to ensure that all of these and any other relevant concerns are covered.

@jeremystretch commented on GitHub (Nov 30, 2020): > I believe the information provided is clear Per my previous comment, it is not. You've shared a vague summary of functionality, but have provided no details concerning its proposed implementation. As an open source project, NetBox relies on its user base to help propose, craft, and implement new features. Please spend more time thinking about what your proposed change looks like and write up a detailed proposal. (There are plenty of other [feature requests](https://github.com/netbox-community/netbox/issues?q=is%3Aissue+is%3Aopen+label%3A%22type%3A+feature%22) you can use for inspiration.) Here's a non-exhaustive list of key topics to get you started: * What specific problem or limitation are you addressing? * What change(s) do you want to make to the data model? * What existing functionality might this break? * What is the estimated performance impact? * How will current users adopt to the new model? * How will filtering work? * How is this change be represented in the REST API? Please update your original post to ensure that all of these and any other relevant concerns are covered.
adam commented 2025-12-29 18:33:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 15, 2020):

Closing due to lack of activity. This may be revisited in the future if anyone would like to open a detailed feature request addressing all of the points above.

@jeremystretch commented on GitHub (Dec 15, 2020): Closing due to lack of activity. This may be revisited in the future if anyone would like to open a detailed feature request addressing all of the points above.
adam commented 2025-12-29 18:33:56 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jan 26, 2023):

Recently @DanSheps and I we were discussing this issue.

Honestly, versioning might be something we could look at adding to core.
For example, you have a basic "Platform" (PC, Network, etc), then you drill down to the Operating system and version.
Heck, it might be enough just to make platform nestable, so like...
PC
|--Microsoft
|--Windows
|--11
|--10
|--8.1
|--8.0
|--7
|--Linux
|--Redhat Enterprise
|--8
Etc

Would allow things like choosing "PC" as the platform for a Dell xxx and then getting more granular from there (I can't remember what was dependent upon Platform but if you chose platform for something it made a few things more difficult, mostly centered around Servers, and not so much around Network Systems)

To answer @jeremystretch questions:

  • What specific problem or limitation are you addressing?
    • A need to model and track specific:
      • Version numbers and possibly file names for said version (filename could be a custom field)
      • A way to identify intended firmware version per devicetype as well as track it over time using the changelog
      • Like other nestable models, a way to show more granular detail about platforms
  • What change(s) do you want to make to the data model?
    • Option 1: Create nestable platforms to model software with a version
    • Option 2: Create a new model relating software version to platforms as well as relating recommended/selected(needs a better name) software versions to a devicetype/device.
  • What existing functionality might this break?
    • It should not break anything
  • What is the estimated performance impact?
    • If a new model, I am unsure, but the same as any model.
    • If just a nestable model, it should be the same impact for all other models we made nestable.
  • How will current users adopt to the new model?
    • Users will leverage this new model or nested feature to show the intended software versions for a device/devicetype. They could then use it like any other netbox model to audit against actual software version deployed or trigger automation workflows to upgrade software.
  • How will filtering work?
    • The same as any other new model, I would imagine users would want to be able to see and filter devices by software version (just like they can with platform).
    • If we set up a nestable approach, we would need to update the filters to match the logic of other nestable models.
  • How is this change be represented in the REST API?
    • New api target if we make a new model
    • Update api to include parent reference for the parent platform.

I am reopening to get this opened up for debate, but we may very well close this issue again.

@ryanmerolle commented on GitHub (Jan 26, 2023): Recently @DanSheps and I we were discussing this issue. > Honestly, versioning might be something we could look at adding to core. > For example, you have a basic "Platform" (PC, Network, etc), then you drill down to the Operating system and version. > Heck, it might be enough just to make platform nestable, so like... > PC > |--Microsoft > |--Windows > |--11 > |--10 > |--8.1 > |--8.0 > |--7 > |--Linux > |--Redhat Enterprise > |--8 > Etc > > Would allow things like choosing "PC" as the platform for a Dell xxx and then getting more granular from there (I can't remember what was dependent upon Platform but if you chose platform for something it made a few things more difficult, mostly centered around Servers, and not so much around Network Systems) To answer @jeremystretch questions: - What specific problem or limitation are you addressing? - A need to model and track specific: - Version numbers and possibly file names for said version (filename could be a custom field) - A way to identify intended firmware version per devicetype as well as track it over time using the changelog - Like other nestable models, a way to show more granular detail about platforms - What change(s) do you want to make to the data model? - Option 1: Create nestable platforms to model software with a version - Option 2: Create a new model relating software version to platforms as well as relating recommended/selected(needs a better name) software versions to a devicetype/device. - What existing functionality might this break? - It should not break anything - What is the estimated performance impact? - If a new model, I am unsure, but the same as any model. - If just a nestable model, it should be the same impact for all other models we made nestable. - How will current users adopt to the new model? - Users will leverage this new model or nested feature to show the intended software versions for a device/devicetype. They could then use it like any other netbox model to audit against actual software version deployed or trigger automation workflows to upgrade software. - How will filtering work? - The same as any other new model, I would imagine users would want to be able to see and filter devices by software version (just like they can with platform). - If we set up a nestable approach, we would need to update the filters to match the logic of other nestable models. - How is this change be represented in the REST API? - New api target if we make a new model - Update api to include parent reference for the parent platform. I am reopening to get this opened up for debate, but we may very well close this issue again.
adam commented 2025-12-29 18:33:56 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Feb 15, 2023):

I think we could safely move this to a discussion to discuss the implementation details

@jsenecal commented on GitHub (Feb 15, 2023): I think we could safely move this to a discussion to _discuss_ the implementation details
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4216
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?