Most Profile Types are unused

[ocket8888]

This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:

• Traffic Ops
• Documentation
• unknown

Current behavior:

Of the allowable Profile Types, only TR_PROFILE, GROVE_PROFILE, and UNK_PROFILE have any use in the logic of any ATC component.

TR_PROFILE is only used when refreshing DNSSEC Keys with /cdns/dnsseckeys/refresh, generating DNSSEC KSKs with /cdns/{{name}}/dnsseckeys/ksk/generate, and when generating a response to a GET request to /cdns/domains.

UNK_PROFILE is only used by Postinstall when inserting the global ATC profile. That Profile can be deleted later although that may break things, and if its Type changes to anything else there will be absolutely zero affect on the behavior of anything in the CDN.

GROVE_PROFILE is only used by grovetccfg when generating configuration when it checks before doing anything that the Profile for the requested host is of that type before proceeding.

So if you don't use Grove or DNSSEC and never look at the output of /cdns/domains, the Type of a Profile literally never matters to you. You can easily assign a DS_PROFILE-type Profile to your Traffic Routers, a SPLUNK_PROFILE-type Profile to all of your Traffic Monitors, RIAK_PROFILE to all of your Delivery Services, etc. and it won't make any difference at all. Only the Parameters on Profiles have any bearing on behavior, really. Even Traffic Portal's UI doesn't care if you assign a LOGSTASH_PROFILE to a cache server, because it doesn't matter and won't break anything. The Traffic Ops API won't even give you so much as a warning if you assign a TR_PROFILE to an Origin.

That means that following Profile Types have absolutely no use, purpose, or meaning throughout all of ATC:

• ATS_PROFILE
• DS_PROFILE
• ES_PROFILE
• INFLUXDB_PROFILE
• KAFKA_PROFILE
• LOGSTASH_PROFILE
• ORG_PROFILE
• RIAK_PROFILE
• SPLUNK_PROFILE
• TM_PROFILE
• TP_PROFILE
• TS_PROFILE

New behavior:

Ideally, the following Profile Types would be removed entirely, as they have no direct relation to ATC at all:

• ES_PROFILE
• KAFKA_PROFILE
• LOGSTASH_PROFILE
• RIAK_PROFILE
• SPLUNK_PROFILE

RIAK_PROFILE included in that list in anticipation of the day we fully drop support for RiakKV as a Traffic Vault provider.

Those can all be coerced to UNK_PROFILE.

There are, unfortunately, still a few places where for some reason a component's behavior depends on a pattern match on the Name of a server's Profile. For instance, if you have a Delivery Service with a Profile that has the correct Type (DS_PROFILE), but the name of its Profile is RASCALLY_WABBIT, then any Parameters assigned to it with the ConfigFile value rascal-config.txt - which one might expect to be used to generate a generic text file with that name using t3c's rules for doing so - will appear in the /cdns/{{name}}/configs/monitoring output's config section for that Delivery Service's CDN. These kind of bizarre connections are totally insane. They shouldn't exist. If you want to know what type of Profile a given Profile is... look at its Type, don't look for patterns in its Name.

Next, we should consider the relationship between a server Type and a Profile Type.

I'm not sure a Traffic Portal or Traffic Stats instance looks at its Profile's Parameters at all. Maybe one or both of those could be removed, but it's probably not a big deal to leave them just in case. Not that it would be hard to add them later.

A Profile's Parameters are interpreted differently by Traffic Monitors, Traffic Routers, and cache servers. To start with, a TRAFFIC_MONITOR-Type server should only be allowed to be assigned TM_PROFILE-type Profiles, and such Profiles should be unassignable to servers of any other Type. Likewise for TRAFFIC_ROUTER-Type servers and TR_PROFILE-type Profiles. This should be enforced by Traffic Portal as well as in the Traffic Ops API.

Of course, that means that Types of certain Names need to be guaranteed to exist, and immutable. Currently, there's no reason to think that e.g. Traffic Monitor servers have any particular Type or that the Type has any particular Name, or that the type TRAFFIC_MONITOR exists at all. Which is a separate problem that I should open a separate issue for.

ATS_PROFILE and GROVE_PROFILE should only be assignable to cache servers. Don't get me started on how cache servers and servers should be separate things. It would also be ideal if they were collapsed into simply CACHE_SERVER_PROFILE. grovetccfg and t3c should be able to honor the configuration of a Profile as declared by operators in whatever way is required by the underlying caching server software. It shouldn't be necessary for a Profile and its Parameters to be aware of the implementation details of the cache servers to which it's assigned.

INFLUXDB_PROFILE is weird, because it's not bundled with ATC, or necessary for it to work, but Traffic Stats uses it, so the notion of InfluxDB servers as ATC objects does exist. I don't think the Parameters of Profiles used by such servers are ever consulted, so what I would recommend is that InfluxDB servers be removed from Traffic Ops altogether, this Profile Type retired, and instead the InfluxDB servers available to a Traffic Stats instance can be made available to it through a configuration file on its local machine. If there is a deep, pressing, urgent, life-or-death NEED for people to be able to see that list through the Traffic Ops API, it can be exposed through a new Traffic Stats API and a TO plugin could be written to proxy for Traffic Stats to accommodate that need. Though I'm personally not a fan of Traffic Ops acting as a proxy for other components' APIs.