Tags enhancements: exclusion groups, model bindings

[candlerb]

Environment

• Python version: 3.5.2
• NetBox version: 2.5.10

Proposed Functionality

I would like Tag objects to be extended in the following two ways:

1. Exclusion groups

   If a tag has an exclusion group assigned, then you cannot add another tag with the same exclusion group value. (Or: all other tags with the same exclusion group are automatically removed)

2. Model bindings

   A tag can be configured with a set of object type(s) that it can be associated with. If this is present, then this tag can only be applied to those types of object.

   This is similar to the feature that Device Roles have today, where they can be marked as usable for VMs or not.

Both of these are optional. If the exclusion group is unset, the tag can be applied regardless of any other tags. If the model binding is unset, then the tag can be applied to any type of object.

Use Case

For exclusion groups:

• Tags for environment such as "Production", "Test", "Staging", "Development". If a particular device or VM has such a tag, it can only be one from this set.
• Tags for physical attributes such as "24-drive-chassis", "36-drive-chassis" where only one can be true
• Tags for responsible team/owner
• Tags for inventory item roles such as "OS disk", "Data disk"

For model bindings:

• Limiting certain tags to inventory items only, e.g. "OS disk", "Data disk"
• Limiting certain tags to devices + VMs, e.g. responsible team
• Limiting certain tags to physical devices only, e.g. "24-drive-chassis", "36-drive-chassis"

This would make tags much less of a free-for-all, especially if Netbox prevents creation of new tags dynamically (#2727)

Note: I am aware that some of the above can also be achieved by means of custom fields with "Selection" data type. I have tried this, and it turns out to be very messy.

1. It messes up the data entry forms and the search forms, with large numbers of fields which are often irrelevant
2. It's hard to have a single custom field shared by multiple models, such as Device+VM (although in principle this should be allowed by the extras_customfield_obj_type join table). EDIT: Netbox does allow the same custom field to be applied to multiple models
3. Inventory Items do not allow custom fields at all (Custom fields on more models #3083), but they do allow tags.

Database Changes

The Tags model would gain:

• a text field for exclusion group
• an array of django_content_type ids

It could also be done in a more normalized fashion, with an explicit exclusion group model and join table; and a join table between tag and django_content_type. Personally I'd keep it simple, but it's just a style choice.

External Dependencies

Relates to other tag enhancements made in 2.6 branch: #2324, #2791

[jeremystretch]

This is way, way overkill for the function tags are intended to provide. A tag is merely a convenient option to allow for arbitrary, opportunistic organization of various resources to complement the structured, constrained fields built into each model. Tags are created on-demand and convey minimal significance. (NetBox v2.6 will add colors and descriptions to the Tag model, which can be added after a tag has been created, but that's it.)

All of the use cases you cite would be better served using a structured field.

Tags for environment such as "Production", "Test", "Staging", "Development". If a particular device or VM has such a tag, it can only be one from this set.

This can be a custom field on Device.

Tags for physical attributes such as "24-drive-chassis", "36-drive-chassis" where only one can be true

This is already conveyed by DeviceType.

Tags for responsible team/owner

See #988

Tags for inventory item roles such as "OS disk", "Data disk"

This might be pushing NetBox's scope a bit: NetBox is not intended to serve as an asset-tracking system. There might be a case to add a role field to InventoryItem, but it would require a separate FR with discussion.

I appreciate the proposal but the work already done in develop-2.6 is as far as we're going to go with tags for the foreseeable future.