Skip to content
This repository was archived by the owner on Nov 24, 2025. It is now read-only.

Add blueprint for a Global Configuration object#7015

Open
ocket8888 wants to merge 1 commit intoapache:masterfrom
ocket8888:blueprint/global-configuration
Open

Add blueprint for a Global Configuration object#7015
ocket8888 wants to merge 1 commit intoapache:masterfrom
ocket8888:blueprint/global-configuration

Conversation

@ocket8888
Copy link
Copy Markdown
Contributor

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.


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

  • This PR doesn't need tests
  • This PR doesn't need documentation
  • This PR doesn't need a CHANGELOG.md entry
  • This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY

@ocket8888 ocket8888 added tech debt rework due to choosing easy/limited solution blueprint feature requirements / implementation details labels Aug 11, 2022
@guzzijason
Copy link
Copy Markdown
Contributor

My understanding is that this addresses #1969 , but its not clear to me just how yet. Does the use of Global Configuration simply make the past use of parameters obsolete?

@ocket8888
Copy link
Copy Markdown
Contributor Author

No, I don't believe this to really be directly related to #1969. This will not obviate the use of Parameters in general. It's only meant to take the place of "global"-like Parameters.

@ocket8888 ocket8888 force-pushed the blueprint/global-configuration branch from ec269a4 to e1a8165 Compare October 11, 2022 20:32
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

blueprint feature requirements / implementation details tech debt rework due to choosing easy/limited solution

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants