Grouped Tags or Tag on Tags

[PieterL75]

I'm looking for a way to 'group' tags.
Currently a Tag is very lonely. You cannot Tag a Tag or set a customfield to a tag.

I would like to be able to Group Tags in some sort of way.
The easiest is to be able to Tag a Tag.
Another option is to create a new TagGroup model, that will be able to groups tags.

Purpose: I have now 5 tags that I can assign to devices (based on the logical core they are part of). This can become a larger group of tags when I onboard more cores. Now I have to adjust my scripts to include the new tags for the new core. It would be very convenient, that I could just readout the members of a TagGroup or all Tags that have the 'CoreTag' tag, removing the static data out of my scipt

Any other ideas ?

[pobradovic08]

I'm not 100% sure I understood your usecase, but could you have one all tag and tag all devices with it and then have additional tags like core-1, core-2, etc. for specific device groups? Then you can only use the all tag in your script to get all devices.

[PieterL75]

That's not really what I am meaning. It will work for what I mea, but it could create incorrect configs (like a core-1 tag set, but not the all tag).

What I really would like to do, is set a TAG to t TAG.
if I set the 'all-cores' tag to all tags with 'core-1, core-2, ...', then I can pull all tags that have 'all-cores', and then all devices that have a 'core-' tag..
(the core- is just an example. I cannot work with prefixes on the tagnames, as thwy would become tooo long, and I dont like a lot of metadata in values)

[mtinberg]

I just wonder if there is a different way of using the built-in features that better maps to the problem you are trying to solve. My understanding is that the tag support is from an external library and generic facility to Django, so changing it would require forking and probably not worth the additional maintenance effort. Could structured data be put into a config_context, local_config_context or a custom_field, or a mix. eg. have a "cores" tag for Devices with a core config and manage a local_config_context with Scripts for the specific core data, or if there is a lot of overlap, maybe have a tag for each variation and a different config_context with your common config json/yaml structure. Thats aside from having a structured naming convention for your tags, eg core_something, core_somethingelse, split by '_' and you can enumerate all somethings with ^core_(.+)$ tags to get the full list in your Scripts without needing to statically define them individually. They might get longer, but hopefully not unusably so, or you can define a convention of short names ^c_(.+)$ that's documented, and your operators can learn. Also could have a Script run periodically that adds tags automatically based on the presense of other manually-curated tags, eg add an 'all-cores' tag if any 'cores_foo' tag exists, if that's useful for searching, since searching for multiple tags gets the intersection of sets and not the union. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: PieterL75 ***@***.***> Sent: Monday, June 26, 2023 5:52 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Grouped Tags or Tag on Tags (Discussion #12963) That's not really what I am meaning. It will work for what I mea, but it could create incorrect configs (like a core-1 tag set, but not the all tag). What I really would like to do, is set a TAG to t TAG. if I set the 'all-cores' tag to all tags with 'core-1, core-2, ...', then I can pull all tags that have 'all-cores', and then all devices that have a 'core-' tag.. (the core- is just an example. I cannot work with prefixes on the tagnames, as thwy would become tooo long, and I dont like a lot of metadata in values) — Reply to this email directly, view it on GitHub<#12963 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5I2OGL7C4UTEOSIYTXNFSXZANCNFSM6AAAAAAZQB2GFM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dgreenzgf]

I'd like to add my name here. We're trying to standardize tags across systems and most tags we use have the format: key:value with Azure being the main one. This would seem to solve that problem by letting us group tags under a key.