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.

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

Xrootd log levels now configurable #660

Merged

Conversation

joereuss12
Copy link
Contributor

Moves many of the xrootd log levels to be configurable. Set defaults in defaults.yaml to what we previously had set.

@joereuss12 joereuss12 requested a review from bbockelm January 12, 2024 22:19
@joereuss12 joereuss12 added this to the v7.5.0 milestone Jan 12, 2024
@joereuss12 joereuss12 linked an issue Jan 12, 2024 that may be closed by this pull request
Comment on lines 20 to 28
XrootdScitokensTrace: all
XrootdPssTrace: all
XrootdCmsTrace: all
XrootdOfsTrace: all
XrootdPfcTrace: info
XrootdXrdTrace: all -sched
XrootdXrootdTrace: emsg login stall redirect
XrootdPssSetOptCache: DebugLevel 3
XrootdPssSetOptOrigin: DebugLevel 1
Copy link
Contributor

@matyasselmeci matyasselmeci Jan 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The defaults are way too verbose and impact performance. Here are the defaults OSG ships with:

Suggested change
XrootdScitokensTrace: all
XrootdPssTrace: all
XrootdCmsTrace: all
XrootdOfsTrace: all
XrootdPfcTrace: info
XrootdXrdTrace: all -sched
XrootdXrootdTrace: emsg login stall redirect
XrootdPssSetOptCache: DebugLevel 3
XrootdPssSetOptOrigin: DebugLevel 1
XrootdScitokensTrace: none
XrootdPssTrace: off
XrootdCmsTrace: -all
XrootdOfsTrace: -all
XrootdPfcTrace: info
XrootdXrdTrace: -all
XrootdXrootdTrace: emsg login stall redirect
XrootdPssSetOptCache: DebugLevel 1
XrootdPssSetOptOrigin: DebugLevel 1

in addition, it would be nice to be able to set http.trace. The default should be none and http.trace all leaks sensitive information but I think http.trace debug or http.trace all -request -response should be safe.

We tell people that if they want to debug they should set

ofs.trace all
xrd.trace all -sched
cms.trace all
scitokens.trace all
pss.setopt DebugLevel 3

Copy link
Contributor

@matyasselmeci matyasselmeci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some opinions about the defaults; the code looks fine at a glance but I'm not familiar enough with the codebase so someone else should look at that.

docs/parameters.yaml Outdated Show resolved Hide resolved
docs/parameters.yaml Outdated Show resolved Hide resolved
docs/parameters.yaml Outdated Show resolved Hide resolved
docs/parameters.yaml Outdated Show resolved Hide resolved
docs/parameters.yaml Outdated Show resolved Hide resolved
docs/parameters.yaml Outdated Show resolved Hide resolved
Copy link
Collaborator

@bbockelm bbockelm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few thoughts:

  1. With @turetske working on configurations where both the cache and origin are running under the same pelican process, we're finding it's bad to have things named generically "Xrootd". We should split it out to "Cache" and "Origin" prefixes.
  2. This gets really into the nitty-gritty of XRootD logging configuration and exposes its inconsistencies. To understand what all -sched does, you need to be an xrootd expert. We use simple logging levels elsewhere -- can we keep in that paradigm?

What about a config like this:

Logging:
   Level: Error
   CategoryLevels:
     CategoryName1: Debug
     CategoryName2: Info
     CategoryName3: Error

Where we then map the different category names to different xrootd configurations.

The downside of the above approach is schema verification is tough. An alternate would be:

Logging:
   Level: Error
   DebugLevel: ["CategoryName1"]
   InfoLevel: ["CategoryName2"]
   ErrorLevel: ["CategoryName3"]

I'm leaning toward the former scheme but open to input.

@matyasselmeci
Copy link
Contributor

CategoryName as in "pfc", "pss", etc.?

@joereuss12 joereuss12 force-pushed the xrootd-config-log-levels-branch branch from 5d5ee0d to 3ab9112 Compare January 24, 2024 19:58
@joereuss12
Copy link
Contributor Author

@bbockelm @matyasselmeci assuming these tests pass, take a look at the changes. Seems to work and is more user friendly. A question I have tho is for the link below, what I should do for Origin_Xrootd since our/osg defaults are very specific? Let me know any feedback and if there are any typos (there was a lot of copy/pasting)

https://github.com/PelicanPlatform/pelican/pull/660/files#diff-7d2d0cf2c84876d1136ec4bb84b2cc80441aa374baa2083b8e91896648808671R215-R222

@matyasselmeci
Copy link
Contributor

Does it catch invalid log levels? It would get frustrating to have CachePfc: degub be silently accepted but give no additional info

@joereuss12
Copy link
Contributor Author

Does it catch invalid log levels? It would get frustrating to have CachePfc: degub be silently accepted but give no additional info

Yes, the else within the mapping should set everything to the default. Should we maybe change it to an else if <category name> == "error" and have an else statement tell the user that it did not understand the config setting and set the log level to the default setting?

The statement:

func mapXrootdLogLevels(xrdConfig *XrootdConfig) {
// Origin Scitokens
originScitokensConfig := param.Logging_Origin_Scitokens.GetString()
if originScitokensConfig == "debug" {
xrdConfig.Logging.OriginScitokens = "all"
} else if originScitokensConfig == "info" {
xrdConfig.Logging.OriginScitokens = "info"
} else { // Default is error
xrdConfig.Logging.OriginScitokens = "none"
}

@matyasselmeci
Copy link
Contributor

Yes, if the user entered an unrecognized value, they should be alerted to that.

@joereuss12
Copy link
Contributor Author

Sounds good, I will make those changes!

Moves many of the xrootd log levels to be configurable. Set defaults in
defaults.yaml to what we previously had set.
This revised to config options to be more user friendly and seperated
them out into `origin` and `cache` categories.
Changes include:
- the user is now notified if their log level config value is invalid
  and it is set to default
- Cms was moved from caches to origins where it should be
- Pss controls now pss.trace and pss.setopt for easier usability
@joereuss12 joereuss12 force-pushed the xrootd-config-log-levels-branch branch from 3ab9112 to 3158bbf Compare January 25, 2024 16:57
@joereuss12
Copy link
Contributor Author

@matyasselmeci @bbockelm Next round of revisions are in! Let me know if there is any more feedback. Some questions/concerns I still have are:

  1. // Origin Xrootd
    // Have this for now with the regular config options, not sure what to do to make it more
    // user-friendly since our/osg's defaults are pretty specific
    originXrootdConfig := param.Logging_Origin_Xrootd.GetString()
    What should I do about Origin_Xrootd log levels? Pelican/osg defaults are pretty specific so not sure how to make it debug/info/error. The default is emsg login stall redirect.

  2. } else if originCmsConfig == "info" {
    xrdConfig.Logging.OriginCms = "-all" // Not super sure what to do for info on this one
    } else if originCmsConfig == "error" {
    xrdConfig.Logging.OriginCms = "-all"
    } else if cacheOfsConfig == "info" {
    xrdConfig.Logging.CacheOfs = "-all" // Not super sure what to do for info on this one
    } else if cacheOfsConfig == "error" {
    xrdConfig.Logging.CacheOfs = "-all"
    } else {
    } else if cacheXrdConfig == "info" {
    xrdConfig.Logging.CacheXrd = "-all" // Not super sure what to do for info on this one
    } else if cacheXrdConfig == "error" {
    xrdConfig.Logging.CacheXrd = "-all"
    } else {
    I am not super sure what to have for the info level for these 3 categories. The default is -all and debug seems like it should just be all so I'm not sure what the middle grounds should be.

@matyasselmeci
Copy link
Contributor

@bbockelm might have ideas but I'd prefer to get this even if "info" doesn't have very good values, and get better values in a later PR.

@jhiemstrawisc
Copy link
Member

@matyasselmeci I chatted with Brian this morning, and he's short on time for a review. After Joe's most recent changes, are you happy with merging this?

Copy link
Contributor

@matyasselmeci matyasselmeci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks!

@jhiemstrawisc jhiemstrawisc merged commit b1a8918 into PelicanPlatform:main Feb 1, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Control XRootD log levels via the Pelican config
4 participants