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

Add a generic model for simple IDs. #6717

New Issue
Closed
opened 2025-12-29 19:44:26 +01:00 by adam · 6 comments
adam commented 2025-12-29 19:44:26 +01:00
Owner
Copy Link

Originally created by @LarsNorlys on GitHub (Jul 26, 2022).

NetBox version

v2.10.x

Feature type

Data model extension

Proposed functionality

Add a generic model for simple serial numbers.
Netbox does not currently contain a model for more generic uses like ESI’s, Simple circuit-id’s or relations with a need for unique ID’s.
In order to make Netbox the central SOT, a generic model supported in the UI, API and pynetbox would be benificial.
Features could be:

  • Unique constraint
  • State (active/reserved/deprecated)
  • Reference to one or more entities (interface/devices/vlans/VRFs)
  • Possible regex data validation.
  • get_next()

Use case

  • Generic Circuit ID
  • Ethernet Segment ID’s
    This value needs to be unique for a given SP network - but can be shared between interfaces for specific use cases
  • Redundancy group
    In order to mark devices for part of a redundant setup - and hence not candidates for upgrades in the same service-window we need to indicate a relation between a service and a set of devices

Database changes

No response

External dependencies

No response

Originally created by @LarsNorlys on GitHub (Jul 26, 2022). ### NetBox version v2.10.x ### Feature type Data model extension ### Proposed functionality Add a generic model for simple serial numbers. Netbox does not currently contain a model for more generic uses like ESI’s, Simple circuit-id’s or relations with a need for unique ID’s. In order to make Netbox the central SOT, a generic model supported in the UI, API and pynetbox would be benificial. Features could be: - Unique constraint - State (active/reserved/deprecated) - Reference to one or more entities (interface/devices/vlans/VRFs) - Possible regex data validation. - get_next() ### Use case - Generic Circuit ID - Ethernet Segment ID’s This value needs to be unique for a given SP network - but can be shared between interfaces for specific use cases - Redundancy group In order to mark devices for part of a redundant setup - and hence not candidates for upgrades in the same service-window we need to indicate a relation between a service and a set of devices ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurepending closurestatus: revisions needed labels 2025-12-29 19:44:26 +01:00
adam closed this issue 2025-12-29 19:44:26 +01:00
adam commented 2025-12-29 19:44:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 26, 2022):

I'm afraid it's not clear from your description what it is you're trying to accomplish.

Add a generic model for simple serial numbers.

Models represent complex objects like site, racks, devices, etc; A serial number would not exist as a separate model.

Please revise your post above to explain exactly what change(s) you're proposing and why it would be beneficial.

@jeremystretch commented on GitHub (Jul 26, 2022): I'm afraid it's not clear from your description what it is you're trying to accomplish. > Add a generic model for simple serial numbers. Models represent complex objects like site, racks, devices, etc; A serial number would not exist as a separate model. Please revise your post above to explain exactly what change(s) you're proposing and why it would be beneficial.
adam commented 2025-12-29 19:44:27 +01:00
Author
Owner
Copy Link

@LarsNorlys commented on GitHub (Jul 27, 2022):

I will try and explain better.

In some cases we would like to have the option to generate and store specific unique IDs in Netbox in order to utilize the single source and providing UI and API in a uniform way.

Boiled down we would like to be able to generate a unique identifier.
Preferably the unique identifier has possibility for validation, auto-prefix and -suffix, being decimal or hex.
If the API/GUI build support get_next_available_id() it would greatly improve accessibility

Use cases in more detail.

Consider a network using eVPN. ESI’s are used to identify unique ethernet segments. ESI are a 10-octet integer.
These can be associated to one or more interfaces. We would like to be able to generate, store and validate these in Netbox - coupled with a Tenant, a description and a state. Functionality for getting the next available value/ESI would be nice.
We see no current ways to store this is Netbox in a meaningful manner
Example:
Name: “ESIpool”
Prefix: “000303”
Suffix: “01”
Type: Hex
Range: 000000000000 - ffffff ffffff
Output: 00030300000000000001, 00030300000000000101 ... 000303ffffffffffff01

Circuit ID: Consider a small network with no big OSS/BSS systems. They want to use Netbox as their sole Source of Truth exposing a circuit and its relations using Netbox’s strong features.
This could be done using a unique identifier generated using a predefined range and regex validation.
Example:
Name: “CircuitIDs”
Prefix: ”CID”
Suffix: None
Type: Decimal
Range: 100000 – 999999
Output: CID100000, CID100001... CID999999

Consider having a redundant customer circuit that on the network provider side terminates in two different network elements/interfaces.
Doing software upgrades on the service provider network without downtime for the redundant circuit will require a way to document the relation between network elements in order to avoid upgrading software at two nodes redundant for each other at the same time. Use case is to do a redundancy group for each relation between network elements.
This could also be used for devices instead of interfaces if one considers a ring structure where simultaneous upgrade of two devices would result in isolated nodes in the ring.
Example:
Name: “RedundacyGroup”
Prefix: ”RDG”
Suffix: None
Type: Decimal
Range: 100000 – 999999
Output: RDG100000, RDG100001... RDG999999

Consideration (as mentioned) has been to propose a list of Netbox objects to each instance of above, but this can be solved using custom fields on the objects or tags, so this part has been left out.

@LarsNorlys commented on GitHub (Jul 27, 2022): I will try and explain better. In some cases we would like to have the option to generate and store specific unique IDs in Netbox in order to utilize the single source and providing UI and API in a uniform way. Boiled down we would like to be able to generate a unique identifier. Preferably the unique identifier has possibility for validation, auto-prefix and -suffix, being decimal or hex. If the API/GUI build support get_next_available_id() it would greatly improve accessibility Use cases in more detail. Consider a network using eVPN. ESI’s are used to identify unique ethernet segments. ESI are a 10-octet integer. These can be associated to one or more interfaces. We would like to be able to generate, store and validate these in Netbox - coupled with a Tenant, a description and a state. Functionality for getting the next available value/ESI would be nice. We see no current ways to store this is Netbox in a meaningful manner Example: Name: “ESIpool” Prefix: “000303” Suffix: “01” Type: Hex Range: 000000000000 - ffffff ffffff Output: 00030300000000000001, 00030300000000000101 ... 000303ffffffffffff01 Circuit ID: Consider a small network with no big OSS/BSS systems. They want to use Netbox as their sole Source of Truth exposing a circuit and its relations using Netbox’s strong features. This could be done using a unique identifier generated using a predefined range and regex validation. Example: Name: “CircuitIDs” Prefix: ”CID” Suffix: None Type: Decimal Range: 100000 – 999999 Output: CID100000, CID100001... CID999999 Consider having a redundant customer circuit that on the network provider side terminates in two different network elements/interfaces. Doing software upgrades on the service provider network without downtime for the redundant circuit will require a way to document the relation between network elements in order to avoid upgrading software at two nodes redundant for each other at the same time. Use case is to do a redundancy group for each relation between network elements. This could also be used for devices instead of interfaces if one considers a ring structure where simultaneous upgrade of two devices would result in isolated nodes in the ring. Example: Name: “RedundacyGroup” Prefix: ”RDG” Suffix: None Type: Decimal Range: 100000 – 999999 Output: RDG100000, RDG100001... RDG999999 Consideration (as mentioned) has been to propose a list of Netbox objects to each instance of above, but this can be solved using custom fields on the objects or tags, so this part has been left out.
adam commented 2025-12-29 19:44:27 +01:00
Author
Owner
Copy Link

@oh-c commented on GitHub (Jul 29, 2022):

I like the idea of having something that creates a uniqe object, with some constraints like the ESI. This coupled with https://github.com/netbox-community/netbox/issues/8157 and a custom field pointing to the generated ESI object would ensure that no overlapping ESI are created.

The L2VPN already has the "identifier" field, but besides regex contraints there is not way to ensure uniquness. This could be extended to be a relation to an object instead of an integer.

@oh-c commented on GitHub (Jul 29, 2022): I like the idea of having something that creates a uniqe object, with some constraints like the ESI. This coupled with https://github.com/netbox-community/netbox/issues/8157 and a custom field pointing to the generated ESI object would ensure that no overlapping ESI are created. The L2VPN already has the "identifier" field, but besides regex contraints there is not way to ensure uniquness. This could be extended to be a relation to an object instead of an integer.
adam commented 2025-12-29 19:44:27 +01:00
Author
Owner
Copy Link

@phurrelmann commented on GitHub (Jul 29, 2022):

what comes next to my mind are cable labels. right now one needs to maintain and generate those outside of netbox. this could mobe the generation of them into netbox and the source of truth

@phurrelmann commented on GitHub (Jul 29, 2022): what comes next to my mind are cable labels. right now one needs to maintain and generate those outside of netbox. this could mobe the generation of them into netbox and the source of truth
adam commented 2025-12-29 19:44:27 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 28, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Sep 28, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:44:27 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 29, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Oct 29, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: revisions needed 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#6717
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?