Config Contexts by Racks #3320

New Issue

adam · 2025-12-29T18:27:40+01:00

adam commented

2025-12-29 18:27:40 +01:00

Originally created by @sakbhav on GitHub (Feb 13, 2020).

Environment

Python version: 3.6.3
NetBox version: 2.7.4

Proposed Functionality

To be able to set config context per rack basis.

Use Case

I want to set some rack specific configurations (e.g. static routes/network switch related configs etc.) via ansible using netbox as inventory. Though this can be achieved by setting a tag and defining config context on that tag but it won't scalable for large number of servers.

Database Changes

Yes

External Dependencies

None

Originally created by @sakbhav on GitHub (Feb 13, 2020).  ### Environment * Python version: 3.6.3 * NetBox version: 2.7.4  ### Proposed Functionality To be able to set config context per rack basis.  ### Use Case I want to set some rack specific configurations (e.g. static routes/network switch related configs etc.) via ansible using netbox as inventory. Though this can be achieved by setting a tag and defining config context on that tag but it won't scalable for large number of servers. ### Database Changes Yes  ### External Dependencies None

adam closed this issue

2025-12-29 18:27:40 +01:00

adam commented

2025-12-29 18:27:41 +01:00

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

I want to set some rack specific configurations (e.g. static routes/network switch related configs etc.)

A device's physical location shouldn't have any bearing on its function, so inferring characteristics of a device from the rack in which it's installed strikes me as backwards. It sounds like you're using the rack as a proxy for some other piece(s) of information, which will inevitably present a problem at some point down the road.

Though this can be achieved by setting a tag and defining config context on that tag but it won't scalable for large number of servers.

Why don't you expect the use of tags to scale?

@jeremystretch commented on GitHub (Feb 13, 2020): > I want to set some rack specific configurations (e.g. static routes/network switch related configs etc.) A device's physical location shouldn't have any bearing on its function, so inferring characteristics of a device from the rack in which it's installed strikes me as backwards. It sounds like you're using the rack as a proxy for some other piece(s) of information, which will inevitably present a problem at some point down the road. > Though this can be achieved by setting a tag and defining config context on that tag but it won't scalable for large number of servers. Why don't you expect the use of tags to scale?

adam commented

2025-12-29 18:27:41 +01:00

@sakbhav commented on GitHub (Feb 15, 2020):

A device's physical location shouldn't have any bearing on its function, so inferring characteristics of a device from the rack in which it's installed strikes me as backwards.

Well, device's physical location does have bearing with its function when we need to reduce the network latency to its minimum.

It sounds like you're using the rack as a proxy for some other piece(s) of information, which will inevitably present a problem at some point down the road.

In my case, I am trying to keep server's static route information (which are different for each rack) in config context.
Rack config context can also be used in a more general case like if you want to set the hostname/alias of servers based on the rack it is present in etc.

Why don't you expect the use of tags to scale?

This will involve tagging all the servers in a rack with same tag which is cumbersome and error prone. Also this is going to be redundant information.

I understand that this use case might not be a very general one, but if this can be easily done and doesn't have huge performance overhead then please enable config context to be defined per rack.

Thanks

@sakbhav commented on GitHub (Feb 15, 2020): > A device's physical location shouldn't have any bearing on its function, so inferring characteristics of a device from the rack in which it's installed strikes me as backwards. Well, device's physical location does have bearing with its function when we need to reduce the network latency to its minimum. > It sounds like you're using the rack as a proxy for some other piece(s) of information, which will inevitably present a problem at some point down the road. In my case, I am trying to keep server's static route information (which are different for each rack) in config context. Rack config context can also be used in a more general case like if you want to set the hostname/alias of servers based on the rack it is present in etc. > Why don't you expect the use of tags to scale? This will involve tagging all the servers in a rack with same tag which is cumbersome and error prone. Also this is going to be redundant information. I understand that this use case might not be a very general one, but if this can be easily done and doesn't have huge performance overhead then please enable config context to be defined per rack. Thanks

adam commented

2025-12-29 18:27:41 +01:00

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

In my case, I am trying to keep server's static route information (which are different for each rack) in config context.

It's not different for each rack: It's different for each prefix, and you just happen to allocate (presumably) one prefix per rack. If one prefix were to span two racks, all the devices in both racks would still use the same gateway. Similarly, there may be two prefixes within a single rack which use different gateways. There is no direct correlation of rack to IP gateway.

I'm going to decline this FR because using a device's rack as a proxy for other information is unnecessary and there are mechanisms available in NetBox better suited for this purpose.

@jeremystretch commented on GitHub (Feb 17, 2020): > In my case, I am trying to keep server's static route information (which are different for each rack) in config context. It's not different for each rack: It's different for each _prefix_, and you just happen to allocate (presumably) one prefix per rack. If one prefix were to span two racks, all the devices in both racks would still use the same gateway. Similarly, there may be two prefixes within a single rack which use different gateways. There is no direct correlation of rack to IP gateway. I'm going to decline this FR because using a device's rack as a proxy for other information is unnecessary and there are mechanisms available in NetBox better suited for this purpose.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#3320