Tagging hosts and sets

Connections carry tags. Button sets carry tags. A set appears on any connection that shares one. Tag a switch cisco and every set tagged cisco is on it — including the ones you install next month.

That last part is the whole point, and it is the thing naming sets on a connection cannot do. A named list is a decision you made about the sets you had at the time. A tag is a description of what the box is, and new sets find it on their own.

Setting it up

1. Edit a connection and give it tags — what the thing is, not what you want on it: cisco, switch, production, customer-acme.
2. That is it. Every shipped set already carries vendor and platform tags, so the matching sets appear immediately with no set editing at all.

Tags are tidied up as you type them: lower-cased, trimmed, and inner spaces turned into hyphens. Customer Acme and customer-acme are the same tag, so two people tagging things months apart still match.

It stacks with the named list

A set shows on a connection if it is named in that connection's list or shares a tag with it. The two are additive, so you can tag broadly and still pin one specific set to one specific host.

A connection with no tags and no named sets still shows everything, which is what every connection you already have looks like after upgrading. Nothing moves until you decide it should.

What to tag things

The useful test is whether the tag describes the host or describes your intention. The shipped sets are tagged by vendor and platform — cisco, fortinet, proxmox, firewall, switching — so tagging hosts the same way costs you nothing and works immediately.

Beyond that, tags are free text and the useful ones tend to be the divisions you already think in: a customer, a site, an environment. Tag a host production and you can keep a set of deliberately careful procedures that only ever appears on production kit.

Shared sets arrive already labelled

Tags travel inside the exported file. Download a set from the exchange, import it, and it starts matching your existing hosts straight away — there is no step where you go and connect it up.

The same words are used on the exchange itself, so the tag you filter a listing by is the tag that decides which of your switches the set lands on.

If you are publishing a set, tagging it before you export is the single most useful thing you can do for whoever downloads it.

On an older build

Nothing breaks. A build before 1.4.0 reads the file, ignores the tags and imports the set exactly as it always did — you place it on connections yourself. That is why the exchange does not badge a tagged set as needing a newer version: it does not.