Guidelines for using tags vs boolean custom fields

[mtinberg]

Do people have opinions on when using tags on objects to show they are enabled for a service vs using boolean custom fields works better? Are there any technical limitations or operational challenges that cause you to prefer one or the other? The functionality seems mostly equivalent, tags are boolean present/not present and custom_fields are trinary, yes/no/undefined. For example I'm starting to model MPLS L2VPN and have both an enable_mpls tag and an enable_mpls boolean custom field, on Device and VRF objects, and was trying to figure out if one way is going to work better than another. I've mostly been using custom fields more than tags but I'm trying to figure out what the engineering trade-offs are before wholly embracing one method or the other for service enablement.

Thoughts, or am I overthinking it?

[markkuleinio]

One thing to note is that you cannot sort objects in GUI based on tags but you can sort by custom fields. Just saying if that is important for you.

[candlerb]

Another is that you can't limit which object types a tag can be assigned to. Your "enable_mpls" tag could be assigned to an IP Address, a Site, a Power Feed etc.

But on the flip side: if you're using the REST API, it's easy to filter on the presence of a tag ("devices with tag foo"), but I couldn't find a way to filter on custom fields ("devices where cf_foo is not empty"). So I've ended up having to do both.

[mtinberg]

tldr; I'm just talking through it...but I think Tags have more utility when used on the Device (and VM) model than boolean custom_fields because they can be used for grouping in Ansible inventory and Config Contexts /ipam/vrfs/?cf_enable_mpls=True (or False) works for me(tm) but I don't think there is any null/unset vs populated check (so maybe not trinary) I've also used /dcim/device-types/?cf_item_sku__gt=0 for numeric fields (xref to internal inventory/financial system in this case) and for string fields ?cf_name__empty should work /static/docs/reference/filtering/ I suppose that if you have a data set queried that is a mix of enabled/disabled items that filtering in software on a custom field with a known name is easier (just a hash existence/value check) than looping over an array of tags to see if the name exists. With tags it's easy to query _across_ data models (at least in the UI) and see where they are applied, I dunno if that's useful though. Tags also have a more compact display in the UI than needing columns of custom fields. Maybe it depends on how many different services a particular object might be associated with, if it's more than a handful then tags might be more managable than dozens of custom field columns, or maybe having a big tag soup without the possibility of longer description/labels/hovertext becomes a usability problem. Some things maybe could use, but that's not a good fit for some of these kinds of things. One area where Tags make sense is in grouping hosts for Ansible playbooks with the Netbox inventory module https://docs.ansible.com/ansible/latest/collections/netbox/netbox/nb_inventory_inventory.html#parameter-group_by so tags on Devices (or maybe using the /ipam/services/ model, which I haven't touched) may have more utility than an equivilant custom field. Tags can also be used with Config Contexts so there is another way that they have more utility. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Brian Candler ***@***.***> Sent: Thursday, January 19, 2023 2:24 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Author ***@***.***> Subject: Re: [netbox-community/netbox] Guidelines for using tags vs boolean custom fields (Discussion #11529) Another is that you can't limit which object types a tag can be assigned to. Your "enable_mpls" tag could be assigned to an IP Address, a Site, a Power Feed etc. But on the flip side: if you're using the REST API, it's easy to filter on the presence of a tag ("devices with tag foo"), but I couldn't find a way to filter on custom fields ("devices where cf_foo is not empty"). So I've ended up having to do both. — Reply to this email directly, view it on GitHub<#11529 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMZTDAWA2U7IFMF53ZTWTD22LANCNFSM6AAAAAAT7IWFDI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[candlerb]

for string fields ?cf_name__empty should work /static/docs/reference/filtering/

I have a custom field called "snmp_module" which gives the SNMP module for Prometheus polling. It's a selection field. The value shows as json null when no value is selected.

To extract a list of targets, I want to get all devices where (cf_)snmp_module is non-null. But I couldn't find a way to do that.

# These return all devices
/api/dcim/devices/?cf_snmp_module__empty
/api/dcim/devices/?cf_snmp_module__empty=

# These return no devices at all
/api/dcim/devices/?cf_snmp_module__empty=true
/api/dcim/devices/?cf_snmp_module__empty=false
/api/dcim/devices/?cf_snmp_module__empty=1
/api/dcim/devices/?cf_snmp_module__empty=0
(they can't all be empty and non-empty!)

# This *does* return all devices where the custom field contains an underscore
/api/dcim/devices/?cf_snmp_module__ic=_

# This *does* return all devices where custom field is non-null and does not contain 'z'
/api/dcim/devices/?cf_snmp_module__nic=z

So I had to add a tag "prom_snmp", and add that as well to the targets, so that the target list was filtered with tag=prom_snmp.

EDIT: Raised as FR #11538

[Kludge-As-A-Service]

One thing I dislike with custom fields is that they apply to all objects, so for example if you need to signal some info relevant to only WAN routers, well too bad you now have an irrelevant new custom field on all your other devices. As you implement more and more use cases, you end up with more and more irrelevant custom fields which clog up the UI. It would be neat if we could configure custom fields so that they are only displayed on objects meeting certain conditions.
So personally I use custom fields when the info apply to all (or most) objects of the selected model, otherwise I use tags.

[candlerb]

One thing I dislike with custom fields is that they apply to all objects

Not exactly true. They don't apply to all objects, but they do apply to all objects of the particular type or types that you have linked the custom field to (e.g. "all devices", "all virtual machines", "all IP addresses" etc)

Tags are worse: they apply to all objects of all types. I think it would be a very nice feature to be able to restrict tags to certain object types, in the same way that custom fields are. Constraining data entry to valid values is always a good thing, as well as reducing the number of choices to scroll through. EDIT: now raised as #11541.

Custom fields are generic (they can be applied to almost any object type), as are tags.

So if you want to control the display and entry of custom fields to a subset of objects, I think the obvious starting point would be to link custom fields to tags as well as object types, so that a given custom field is only displayed if the object has a particular tag. Would that be sufficiently useful? If so, feel free to raise FR, and if it's accepted, to submit a patch :-) EDIT: looks like this has been recently raised as #11367.

I'm not sure what should happen to CF data if the tag is subsequently removed. Either you always display non-empty CF data, or you have to delete the custom field data when the tag is removed (dangerous), or you have to prevent the removal of the tag (perhaps the safest option).

[Kludge-As-A-Service]

I don't really agree that tags are worse, in the sense that by default they aren't clogging the UI. Now if a user erroneously puts a tag where it shouldn't be, that's more a user limitation than a netbox limitation, so less of an issue for me.
I would work on a patch if I had the coding skills for that but unfortunately that's not the case. Hopefully #11367 or something similar gets implemented at some point!

[llamafilm]

This is great discussion topic. I just started asking myself the same question, and found the pros and cons described here very helpful. I think a concise version of these guidelines could go in the official documentation.

[candlerb]

Note that some of the info in this thread is a bit out of date. Since v3.6.0, tags can now be limited to object types; and since v3.7.0 you can adjust the visibility of custom fields, so that (for example) custom fields are only visible if they have been set to a non-null value.