ocket8888 opened a new pull request, #7015:
URL: https://github.com/apache/trafficcontrol/pull/7015

   Currently, we use a ton of  "global" Parameters to configure large-scale 
settings for ATC instances. Not only are many of these undocumented, but they 
are by nature prone to human error. Any user (with the right Permissions) could 
accidentally delete the Parameter, or associate it with the wrong Profile (or 
no Profile at all which is only sometimes a problem), or make a value that may 
seem correct and they are given no warning or error by either TP or the TO API 
but the value is invalid or unusable. And of course in nearly every case it's 
possible that more than one Parameter that something would use exists, because 
multiple Parameters by the same Name and with the same Config File can exist 
with differing Values. In these cases, the value that's actually used any given 
time a component checks the Parameter is an implementation detail of PostgreSQL 
(at best).
   
   Naturally, what "global" means is also highly nebulous. There are some 
instances where a component checks for a Parameter with some given Name, with 
no other criteria, so any Parameter with that name assigned to any Profile of 
any Profile Type in any 
   CDN - or not assigned to any Profile(s) at all - with that Name will be 
considered "global" under some circumstances. Sometimes a check is made for a 
Parameter with a specific Name assigned to a Profile with the Name "GLOBAL" 
(which may or may not exist, can be in any CDN, have any Profile Type, and be 
assigned to any server(s) and/or Delivery Service(s)). Sometimes a check is 
made for some Parameter with a specific name and the Config File value 
"global". Sometimes something will look for a Parameter in the `CRConfig.json` 
Config File. And there are checks for any combination of these restrictions.
   
   Instead, it would be more deterministic, easier to use, more visible, and 
enable validation of settings if there were just a single "Global 
Configuration". Furthermore, components would no longer need to handle the case 
where a setting does not exist.
   
   <hr/>
   
   ## Which Traffic Control components are affected by this PR?
   None.
   
   ## What is the best way to verify this PR?
   Read the blueprint.
   
   ## PR submission checklist
   - [x] This PR doesn't need tests
   - [x] This PR doesn't need documentation
   - [x] This PR doesn't need a CHANGELOG.md entry
   - [x] This PR **DOES NOT FIX A SERIOUS SECURITY VULNERABILITY**


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to