CDN Locks don't cover profile/param changes

[jhg03a]

This Bug Report affects these Traffic Control components:

• Traffic Ops

Current behavior:

CDN locks don't include profiles/params.

Expected behavior:

CDN locks should extend to cover profiles/parameters to prevent changes in configs during times where a lock is held and could slip through if servers are queued or already queued at the time the lock is placed. Parameters themselves are not linked to a CDN directly, but rather indirectly through a profile.

Steps to reproduce:

1. Lock a CDN
2. Update a parameter
3. Observe it let you

[ocket8888]

I really think we ought not to let people modify "Parameters" as a first-class object. It's confusing at best. Like if you have a Profile A with some Parameter in CDN 1, then make Profile B in CDN 2 and use a POST request to /profiles/{{ID}}/parameters to add a Parameter to Profile B, then if it just so happens to have the same name, "ConfigFile", and value as some Parameter on A, you have silently created "linked" Profiles such that modifying the Parameter of one you actually now change two Profiles - escaping the CDN assignment boundary between them as well. TP will warn you of this, but automation gets nothing.

Even through Traffic Portal that has problems, because once you get into that situation the only way around it is to delete the Parameter from one Profile and then create a new Parameter with the value you want it to have and then assign it back to the Profile again. A three step process to change as little as one character.

For my money, Parameters ought to be nothing more than a collection property of Profiles. Especially now that we have the ability to clone and export/import Profiles to reduce the effort to reproduce common configurations, and Profile layering to reduce duplication of configuration.

Maybe something of a tangent for this issue, but it would solve it.