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

Replace regex-based natural ordering of interfaces with a discrete field #2539

New Issue
Closed
opened 2025-12-29 18:19:47 +01:00 by adam · 7 comments
adam commented 2025-12-29 18:19:47 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Apr 22, 2019).

Environment

  • Python version: 3.5.2
  • NetBox version: 2.5.10

Proposed Functionality

The current form of natural ordering for device interfaces was introduced in #2165. It employs a set of regular expressions evaluated at query time to determine the preferred order of rows being returned. This is generally not an issues when retrieving only the interfaces which belong to a particular device, however it imposes excessive delay when querying a large number of interfaces.

Now that the natural ordering logic is fairly mature, I'd like to ditch the regex-based ordering and instead save the ordering data in a dedicated field as an index on the Interface model. Logic similar to the regex currently in use will be evaluated when an object is being saved, and its output will be stored in the database. (A schema migration will take care of updating this field for all existing interfaces.)

The exact nature of the ordering data is yet to be determined.

Use Case

This approach will allow for much more efficient querying and greatly simplify the Interface manager.

Database Changes

  • Add one or more fields to the Interface model
  • Simplify or remove InterfaceManager

External Dependencies

None

Originally created by @jeremystretch on GitHub (Apr 22, 2019). ### Environment * Python version: 3.5.2 * NetBox version: 2.5.10 ### Proposed Functionality The current form of natural ordering for device interfaces was introduced in #2165. It employs a set of regular expressions evaluated at query time to determine the preferred order of rows being returned. This is generally not an issues when retrieving only the interfaces which belong to a particular device, however it imposes excessive delay when querying a large number of interfaces. Now that the natural ordering logic is fairly mature, I'd like to ditch the regex-based ordering and instead save the ordering data in a dedicated field as an index on the Interface model. Logic similar to the regex currently in use will be evaluated when an object is being saved, and its output will be stored in the database. (A schema migration will take care of updating this field for all existing interfaces.) The exact nature of the ordering data is yet to be determined. ### Use Case This approach will allow for much more efficient querying and greatly simplify the Interface manager. ### Database Changes * Add one or more fields to the Interface model * Simplify or remove InterfaceManager ### External Dependencies None
adam added the status: acceptedtype: housekeeping labels 2025-12-29 18:19:47 +01:00
adam closed this issue 2025-12-29 18:19:47 +01:00
adam commented 2025-12-29 18:19:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 22, 2019):

I've played around with this a bit and I think it will be doable, but I need to figure out how best to store the values. Ordering is by:

  • Slot
  • Subslot
  • Position
  • Subposition
  • Type (alphanumeric)
  • ID
  • Channel
  • Virtual circuit

While it's possible to order on an array of numeric values, having the alphanumeric "type" value in the middle of the fields presents a problem. I'm also wondering if this is going down the wrong path, since ultimately we'll want to do something similar for other device components that may need different logic.

@jeremystretch commented on GitHub (Apr 22, 2019): I've played around with this a bit and I think it will be doable, but I need to figure out how best to store the values. Ordering is by: * Slot * Subslot * Position * Subposition * Type (alphanumeric) * ID * Channel * Virtual circuit While it's possible to order on an array of numeric values, having the alphanumeric "type" value in the middle of the fields presents a problem. I'm also wondering if this is going down the wrong path, since ultimately we'll want to do something similar for other device components that may need different logic.
adam commented 2025-12-29 18:19:49 +01:00
Author
Owner
Copy Link

@millijuna commented on GitHub (Apr 23, 2019):

The one thing I would still like to ask for is some way to control the ordering precedence. Right now, my biggest annoyance with Netbox is that it fouls up the ordering when dealing with the interfaces on my Cisco gear. This is because Cisco puts different interface types on the same subslot. As such, on my 3750Es, the ten gig interfaces are mixed into the middle of the GigabitEthernet, and a similar thing happens with the 3560s and so forth.

If there was some way to adjust the ordering precedence, so that I could have Slot, Subslot, Type, Position, Subposition would make me a happy camper.

@millijuna commented on GitHub (Apr 23, 2019): The one thing I would still like to ask for is some way to control the ordering precedence. Right now, my biggest annoyance with Netbox is that it fouls up the ordering when dealing with the interfaces on my Cisco gear. This is because Cisco puts different interface types on the same subslot. As such, on my 3750Es, the ten gig interfaces are mixed into the middle of the GigabitEthernet, and a similar thing happens with the 3560s and so forth. If there was some way to adjust the ordering precedence, so that I could have Slot, Subslot, Type, Position, Subposition would make me a happy camper.
adam commented 2025-12-29 18:19:49 +01:00
Author
Owner
Copy Link

@rkandilarov commented on GitHub (Apr 26, 2019):

I would also like to have control over the ordering... But should this be per device? In our company ( extreme edge case) we have lot of virtual interfaces on some devices named like client.1234 (client.1234@interface) and I would like to see all "subinterfaces" right after the "base" interface.
But to be honest I doubt if such hipper customisation-feature deserves all the work hours.

P.S. Normally the prefix name of the virtual vlan interface is the same as the interface itself. Naming like client.1234@interface or more precisely virtual vlan interface client.1234 on real interface interface is possible using Cumulus Linux ifupdown2 tool on any Debian based linux.

@rkandilarov commented on GitHub (Apr 26, 2019): I would also like to have control over the ordering... But should this be per device? In our company ( extreme edge case) we have lot of virtual interfaces on some devices named like `client.1234` (`client.1234@interface`) and I would like to see all "subinterfaces" right after the "base" `interface`. But to be honest I doubt if such hipper customisation-feature deserves all the work hours. P.S. Normally the prefix name of the virtual vlan interface is the same as the interface itself. Naming like `client.1234@interface` or more precisely virtual vlan interface `client.1234` on real interface `interface` is possible using Cumulus Linux [ifupdown2](https://github.com/CumulusNetworks/ifupdown2) tool on any Debian based linux.
adam commented 2025-12-29 18:19:49 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Dec 28, 2019):

I played around with using a PostgreSQL composite field in https://github.com/steffann/netbox/tree/3097-interface-ordering. I'm not completely happy with the dependency and its implementation, but it seems to work.

@steffann commented on GitHub (Dec 28, 2019): I played around with using a PostgreSQL composite field in https://github.com/steffann/netbox/tree/3097-interface-ordering. I'm not completely happy with the dependency and its implementation, but it seems to work.
adam commented 2025-12-29 18:19:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 30, 2019):

@steffann That's an interesting approach! I have some reservations however about introducing new dependencies without fully mature migration support. Does it provide any significant benefit (other than convenience) over just adding the interface name part fields to the Interface model directly?

@jeremystretch commented on GitHub (Dec 30, 2019): @steffann That's an interesting approach! I have some reservations however about introducing new dependencies without fully mature migration support. Does it provide any significant benefit (other than convenience) over just adding the interface name part fields to the Interface model directly?
adam commented 2025-12-29 18:19:49 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Dec 30, 2019):

@steffann That's an interesting approach! I have some reservations however about introducing new dependencies without fully mature migration support. Does it provide any significant benefit (other than convenience) over just adding the interface name part fields to the Interface model directly?

Nope, just convenience and simple ordering (order_by('_name_components') compared to order_by('_slot', '_subslot', '_position', '_subposition', '_type', '_id', '_channel', '_vc')). Technically embedding a kind of row type in another row boils down to logically equivalent to just adding more columns…

@steffann commented on GitHub (Dec 30, 2019): > @steffann That's an interesting approach! I have some reservations however about introducing new dependencies without fully mature migration support. Does it provide any significant benefit (other than convenience) over just adding the interface name part fields to the Interface model directly? Nope, just convenience and simple ordering (`order_by('_name_components')` compared to `order_by('_slot', '_subslot', '_position', '_subposition', '_type', '_id', '_channel', '_vc')`). Technically embedding a kind of row type in another row boils down to logically equivalent to just adding more columns…
adam commented 2025-12-29 18:19:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 21, 2020):

This was implemented under #3799.

@jeremystretch commented on GitHub (Feb 21, 2020): This was implemented under #3799.
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 status: accepted type: housekeeping
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#2539
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?