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

Allow custom fields to be used for config context assignment #9229

New Issue
Closed
opened 2025-12-29 20:47:17 +01:00 by adam · 3 comments
adam commented 2025-12-29 20:47:17 +01:00
Owner
Copy Link

Originally created by @aaron-iles on GitHub (Feb 12, 2024).

NetBox version

v3.7.2

Feature type

New functionality

Proposed functionality

Currently we are limited to 13 different "selectors" that can be used to assign a config context to a device. Allowing a custom field to be used for config context assignment would give us the flexibility to drill down provisioning to a more granular level.

This would be slightly different from the other selectors since it would require one to add the custom field name and the value of that custom field.

Use case

We use custom fields to track things like the Ansible hostgroup to which a device is assigned. We use the Ansible hostgroup to differentiate software loads on particular servers. This is almost satisfied by "Platform", but we use that for more fine-grained control of slight differences in the Ansible hostgroup.
ie:

  • server A is assigned to hostgroup "web_servers" with platform "web-servers 1.0"
  • server B is assigned to hostgroup "web_servers" with platform "web-servers 1.0"
  • a set of config contexts needs to be applied to all hosts in the "web_servers" Ansible hostgroup
  • server B is undergoing testing to try out a new web server format
  • server B remains in hostgroup "web_servers" but gets its platform changed to "web-servers 2.0"
    The only way to resolve the issue above is update the config context to apply to both platforms "web-servers 1.0" and "web-servers 2.0" as selectors.

Database changes

Not that I can think of.

External dependencies

No response

Originally created by @aaron-iles on GitHub (Feb 12, 2024). ### NetBox version v3.7.2 ### Feature type New functionality ### Proposed functionality Currently we are limited to 13 different "selectors" that can be used to assign a config context to a device. Allowing a custom field to be used for config context assignment would give us the flexibility to drill down provisioning to a more granular level. This would be slightly different from the other selectors since it would require one to add the custom field name **and** the value of that custom field. ### Use case We use custom fields to track things like the Ansible hostgroup to which a device is assigned. We use the Ansible hostgroup to differentiate software loads on particular servers. This is almost satisfied by "Platform", but we use that for more fine-grained control of slight differences in the Ansible hostgroup. ie: - server A is assigned to hostgroup "web_servers" with platform "web-servers 1.0" - server B is assigned to hostgroup "web_servers" with platform "web-servers 1.0" - a set of config contexts needs to be applied to all hosts in the "web_servers" Ansible hostgroup - server B is undergoing testing to try out a new web server format - server B remains in hostgroup "web_servers" but gets its platform changed to "web-servers 2.0" The only way to resolve the issue above is update the config context to apply to both platforms "web-servers 1.0" and "web-servers 2.0" as selectors. ### Database changes Not that I can think of. ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:47:17 +01:00
adam closed this issue 2025-12-29 20:47:17 +01:00
adam commented 2025-12-29 20:47:18 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Feb 13, 2024):

Config contexts can already be applied to tags for the kind of granular control that you seem to be looking for. You would just need to define tags for each of your host groups and apply them, instead of using a custom property. That's how we manage Ansible host groups in our environment today. You just need to be careful if you have hosts that are part of multiple groups and are using lists in your config context, as they get overwritten and not merged at the moment.

@sleepinggenius2 commented on GitHub (Feb 13, 2024): Config contexts can already be applied to tags for the kind of granular control that you seem to be looking for. You would just need to define tags for each of your host groups and apply them, instead of using a custom property. That's how we manage Ansible host groups in our environment today. You just need to be careful if you have hosts that are part of multiple groups and are using lists in your config context, as they get overwritten and not merged at the moment.
adam commented 2025-12-29 20:47:18 +01:00
Author
Owner
Copy Link

@aaron-iles commented on GitHub (Feb 14, 2024):

I appreciate the idea, but unfortunately we use tags for other things. If we switched to using tags for the hostgroup then we could end up with conflicts or hosts in multiple groups that they shouldn't be in.

@aaron-iles commented on GitHub (Feb 14, 2024): I appreciate the idea, but unfortunately we use tags for other things. If we switched to using tags for the hostgroup then we could end up with conflicts or hosts in multiple groups that they shouldn't be in.
adam commented 2025-12-29 20:47:18 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Feb 14, 2024):

I guess I'm still not understanding why using tags would cause issues as described. A common pattern I see is to namespace tags, so you would have something like name="hostgroup:web_servers", slug="hostgroup_web_servers", then on the provisioning side you would filter for any tags with a slug that starts with "hostgroup_" or a name that starts with "hostgroup:" and strip off that prefix. If you have a business requirement that a given server can only be part of a single host group, then you can write a custom validator to enforce that, or even more complex validations, like if a server is "hostgroup:web_server" that it can't also be "hostgroup:mail_server", or whatever your business rules are. For reference, this is exactly how our tags are structured and validation is done.

@sleepinggenius2 commented on GitHub (Feb 14, 2024): I guess I'm still not understanding why using tags would cause issues as described. A common pattern I see is to namespace tags, so you would have something like `name="hostgroup:web_servers", slug="hostgroup_web_servers"`, then on the provisioning side you would filter for any tags with a slug that starts with "hostgroup_" or a name that starts with "hostgroup:" and strip off that prefix. If you have a business requirement that a given server can only be part of a single host group, then you can write a custom validator to enforce that, or even more complex validations, like if a server is "hostgroup:web_server" that it can't also be "hostgroup:mail_server", or whatever your business rules are. For reference, this is exactly how our tags are structured and validation is done.
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 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#9229
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?