netbox
netbox copied to clipboard
netbox-community
Allow custom fields to be used for config context assignment
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
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.
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.
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.