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

[jeremystretch]

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

[jeremystretch]

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.

[millijuna]

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.

[rkandilarov]

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.

[steffann]

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.

[jeremystretch]

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

[steffann]

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

[jeremystretch]

This was implemented under #3799.