Well the blueprint doesn't suggest adding tags to everything. It _does_, though, add them to more than DSes and Servers. Specifically, it includes
- Delivery Services - Servers - Physical Locations - Origins - Profiles - Cache Groups - Users - Topologies - Tenants Which is a lot. We just made up a list of all the things on which it might be useful to have tags (I also pitched Roles, but that was deemed to be adding unnecessary complexity). If you think it's too much stuff, I have no problem taking them off of everything except probably servers and Delivery Services. Just in case it influences you in any way, that list above is in the order of "most important to have tags" to "least important to have tags", IMO. On Tue, Jun 23, 2020 at 11:46 AM Rawlin Peters <[email protected]> wrote: > I think I've only heard this idea tossed around for delivery services > and possibly servers. Why do we need to add tags for all resources in > TO? That seems to add unnecessary complexity to the entire API when > maybe it's only really valuable for a couple resources. > > - Rawlin > > On Tue, Jun 23, 2020 at 11:17 AM ocket 8888 <[email protected]> wrote: > > > > Hello everyone, I wanted to put a new feature blueprint for which I just > > opened a PR on your radar: > > > > https://github.com/apache/trafficcontrol/pull/4819 > > > > The tl;dr is that it's a blueprint for adding Tags to Traffic Ops, which > I > > think is a pretty long-requested - and even worked-around - feature. Tags > > are simple alphanumeric strings with no implied meaning that can be > applied > > to things like servers and Delivery Services (see blueprint for full > list). > > > > Should be a pretty non-invasive change if you don't care about them, > just a > > new optional object property in a few places. >
