Add sub-category under Platforms to track firmware version

ledgley commented 4 years ago

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.

jeremystretch commented 4 years ago

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?

ledgley commented 4 years ago

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.

jeremystretch commented 4 years ago

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?

ledgley commented 4 years ago

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 3 years ago

@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?

jeremystretch commented 3 years ago

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 3 years ago

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.

ryanmerolle commented 1 year ago

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.

jsenecal commented 1 year ago

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

netbox-community / netbox