Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consolidate configuration option hierarchies #130

Closed
jhiemstrawisc opened this issue Sep 13, 2023 · 1 comment
Closed

Consolidate configuration option hierarchies #130

jhiemstrawisc opened this issue Sep 13, 2023 · 1 comment
Assignees
@jhiemstrawisc
Labels
enhancement New feature or request
Milestone
v7.1.0

Comments

@jhiemstrawisc
Copy link
Member

We should make the options configurable via pelican.yaml more consistent and hierarchical. For example, there's an option Director.DefaultResponse that is clearly an option to configure behavior for a director instance. Elsewhere, we have options that configure the director like "MaxMindKeyFile" and "GeoIPLocation", but it's not immediately obvious from the name what service(s) these affect. I think we should make these types of configurations hierarchical so that we wind up with a config more like:

Director:
    DefaultResponse: cache
    MaxMindKeyFile: /path/to/kf
    GeoIPLocation: /path/to/location
@jhiemstrawisc jhiemstrawisc added this to the v7.1.0 milestone Sep 13, 2023
@bbockelm
Copy link
Collaborator

I've been thinking about the same thing!

Can you create a spreadsheet with the following columns:

  • Current parameter name
  • Component name (or blank for top-level)
  • New parameter name

and take a first stab at the renaming? Implicit in this is that I'd like to avoid deeply nested hierarchies of parameter names.

The earlier we do this, the less backward compatibility around renaming we need to do.

@bbockelm bbockelm added the enhancement New feature or request label Oct 1, 2023
jhiemstrawisc added a commit to jhiemstrawisc/pelican that referenced this issue Oct 4, 2023
@jhiemstrawisc
Overhaul config names
f5ab465 
In issue PelicanPlatform#130 we discussed making config variables hierarchical, such that each variable
describes which service it affects. One goal was to keep the hierarchies flat (<= 2 layers).
This PR breaks out the config variables and assigns them to various parent services. It also
adds many new viper config variables to `docs/parameters.yaml` so that users can figure out
which components of Pelican they have control over.
@jhiemstrawisc jhiemstrawisc mentioned this issue Oct 4, 2023
Merged
bbockelm pushed a commit to jhiemstrawisc/pelican that referenced this issue Oct 5, 2023
@jhiemstrawisc @bbockelm
Overhaul config names
d74f632 
In issue PelicanPlatform#130 we discussed making config variables hierarchical, such that each variable
describes which service it affects. One goal was to keep the hierarchies flat (<= 2 layers).
This PR breaks out the config variables and assigns them to various parent services. It also
adds many new viper config variables to `docs/parameters.yaml` so that users can figure out
which components of Pelican they have control over.
jhiemstrawisc added a commit to jhiemstrawisc/pelican that referenced this issue Oct 5, 2023
@jhiemstrawisc
Overhaul config names
1652375 
In issue PelicanPlatform#130 we discussed making config variables hierarchical, such that each variable
describes which service it affects. One goal was to keep the hierarchies flat (<= 2 layers).
This PR breaks out the config variables and assigns them to various parent services. It also
adds many new viper config variables to `docs/parameters.yaml` so that users can figure out
which components of Pelican they have control over.
jhiemstrawisc added a commit to jhiemstrawisc/pelican that referenced this issue Oct 5, 2023
@jhiemstrawisc
Overhaul config names
cf43e0d 
In issue PelicanPlatform#130 we discussed making config variables hierarchical, such that each variable
describes which service it affects. One goal was to keep the hierarchies flat (<= 2 layers).
This PR breaks out the config variables and assigns them to various parent services. It also
adds many new viper config variables to `docs/parameters.yaml` so that users can figure out
which components of Pelican they have control over.
jhiemstrawisc added a commit to jhiemstrawisc/pelican that referenced this issue Oct 5, 2023
@jhiemstrawisc
Overhaul config names
32aed85 
In issue PelicanPlatform#130 we discussed making config variables hierarchical, such that each variable
describes which service it affects. One goal was to keep the hierarchies flat (<= 2 layers).
This PR breaks out the config variables and assigns them to various parent services. It also
adds many new viper config variables to `docs/parameters.yaml` so that users can figure out
which components of Pelican they have control over.
bbockelm pushed a commit to jhiemstrawisc/pelican that referenced this issue Oct 6, 2023
@jhiemstrawisc @bbockelm
Overhaul config names
26266f6 
In issue PelicanPlatform#130 we discussed making config variables hierarchical, such that each variable
describes which service it affects. One goal was to keep the hierarchies flat (<= 2 layers).
This PR breaks out the config variables and assigns them to various parent services. It also
adds many new viper config variables to `docs/parameters.yaml` so that users can figure out
which components of Pelican they have control over.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jhiemstrawisc jhiemstrawisc

Labels
enhancement New feature or request
Projects
None yet
Milestone
v7.1.0
Development

No branches or pull requests
2 participants
@bbockelm @jhiemstrawisc