Incorrect log level derivations in `pelican{-server} config`

[jhiemstrawisc]

This comes from some futzing in the CHTC_PELICAN_CACHE, which was running v7.23.0 at the time.

It seems like there's something strange going on with the log level hierarchy, wherein setting Logging.Level: foo should cause all unpinned log levels under Logging.Cache and Logging.Origin to inherit the value foo. For some reason I can't figure out, it doesn't seem like that inheritance is happening.

Here's the output from the Logging section of pelican-server config dump:

Logging:
    Cache:
        Http: info
        Lotman: info
        Ofs: info
        Pfc: debug
        Pss: debug
        PssSetOpt: debug
        Scitokens: fatal
        Xrd: info
        Xrootd: info
    Client:
        ProgressInterval: 1m0s
    DisableProgressBars: false
    Level: debug
    LogLocation: /var/log/pelican/pelican.log
    Origin:
        Cms: info
        Http: info
        Ofs: info
        Oss: info
        Scitokens: fatal
        Xrd: info
        Xrootd: info

Note that Logging.Cache.{Pfc,Pss,PssSetOpt} were all pinned in config, but none of the other values were. Additionally, Logging.{Cache,Origin}.Scitokens is intentionally cranked down, so it's safe to ignore those right now. Despite Logging.Level: debug, none of the other knobs are inheriting the correct value.

More concerning, the output from pelican-server config dump disagrees with what I can see via the web UI where the values appear to have the correct inheritance:

So which of these two is correct? To answer that I looked at the generated XRootD configuration and then compared it against the Pelican-->XRootD log mapping defined here:

$ cat /run/pelican/xrootd/cache/xrootd.cfg
<abridged>
pss.debug
pfc.trace debug
pss.setopt DebugLevel 4
pss.trace on
ofs.trace debug
xrd.trace debug
xrootd.trace debug emsg login stall redirect request stall
scitokens.trace debug info warning error
http.trace all

From this, the answer is that the Web UI is correct, while pelican-server config dump lies.

I'll note that I manually traced through the chained config files, and made sure pelican-server config dump was pointed at the right entrypoint. I also confirmed the web UI config file at /etc/pelican/web-config.yaml was empty, and saw no evidence this file location was overridden by other yaml config.

I attempted to poke at this locally by checking out the v7.23.0 tag, but I couldn't reproduce.