-
Notifications
You must be signed in to change notification settings - Fork 11
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
chore: named callbacks ADR #676
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Case Wylie <cmwylie19@defenseunicorns.com>
Could you show a compete example of what this would look like? |
Signed-off-by: Case Wylie <cmwylie19@defenseunicorns.com>
adr/0008-named-callbacks.md
Outdated
@@ -0,0 +1,55 @@ | |||
# 7: LogAs Function in Capability Class "Named Callbacks" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"LogAs" seems kinda limited to me. 🤔
We talked about this being a general purpose feature that could / would (essentially) carry a label for any given callback around throughout the Pepr system, right? As it stands, the only place we're currently showing callback function names is in the log messages but that's not all we think can / will be done with this IMO, and I'd like to try to avoid handicapping ourselves by giving it an overly limiting name.
What would you say to naming this something that hinted at a more general usage? Something like:
- Alias()
- Designation()
- Handle()
- or maybe simply, As()
All of those give a good sense of what we want this new func to be thought of as without necessarily limiting it to logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting prospect here, not opposed by any means. Where else other than logs do you see this name being used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We like Alias because a user who has not read the docs is most likely to interpret this as a name.
- Pepr Sync
Added suggestion by @btlghrants Co-authored-by: Barrett <81570928+btlghrants@users.noreply.github.com>
committing suggestion Co-authored-by: Barrett <81570928+btlghrants@users.noreply.github.com>
Co-authored-by: Barrett <81570928+btlghrants@users.noreply.github.com>
Was chatting with @brandtkeller about a Lula use-case where they need to validate that certain policies exist and it seems like this could be a useful mechanism to tell a compliance tool what a binding is responsible for. When(a.Pod)
.IsCreatedOrUpdated()
.Validate(po => {
// reject is running as root, or is privileged, etc
})
.Alias("reject:pods:runAsRoot:privileged:runAsGroup<10:allowPrivilegeEscalation") going to go ahead and get this prioritized because the Lula team needs it. |
We need to verify that we are able to inject the name of the If it were possible it would need to be done with the const Log = pino({
transport,
timestamp: pinoTimeFunction,
}); and import that into the mutate processor and set
|
Description
Pepr is a system of callbacks that produce logs. The callbacks are anonymous, so debugging which log comes from which callback can be confusing unless you manually write a name in the log message from within the callback. This consideration needs an ADR.
Related Issue
Fixes #675
Relates to #
Type of change
Checklist before merging