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

Add access log refactor proposal #10

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

steven-zou
Copy link
Contributor

Add access log refactor proposal

Signed-off-by: Steven Zou szou@vmware.com

Signed-off-by: Steven Zou <szou@vmware.com>
@ghost
Copy link

ghost commented Oct 18, 2018

Hi @steven-zou – this is awesome! I suspect that logging to external syslog server(s) is out of scope for this proposal, particularly considering K8s will handle much of that log consolidation for us. I do see a strong use case for logging over the network, however.

Just wanted to throw that out there.


## Background

The current access log is designed specific for container image related. It's lack of enough flexibility to enable new operations or new target resource type. Additionally, the information contained in the access log is not rich enough for auditing usage.
Copy link

Choose a reason for hiding this comment

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

nit:

  • s/It's/It
  • s/auditing usage/auditing purposes

@ghost
Copy link

ghost commented Oct 18, 2018

Additional feedback from @goharbor/all-maintainers would be great.

Copy link
Contributor

@nlowe nlowe left a comment

Choose a reason for hiding this comment

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

I like this idea, I know we have a few departments who would definitely be interested in this data. This sounds more like an Audit log than an access log. When I think access log I think logs from a web server (response code, request type, URL, IP addresses, etc. etc.)

A few things I'd love to see clarified:

  • Who is responsible for generating UID's?
    • The application? If so, at what point does UID's get generated? When the context is injected? When an event is published?
    • The handlers? If so, do they all generate their own ID's? If they don't, we now have a special handler (the database?) that's responsible for doing more than just "handling" events.
  • Can you give some examples of what the Metadata fields would be used for? I'm not sure I see a use for them. Assuming all of the handlers live in-repo, I think this can be taken care of on the deserialization side for remote / webhook-styloe applications that listen for these events which can be configured to ignore unknown fields until developers get around to updating them.

@ludz-lim
Copy link

Any chance that logging with source IP will be released in the near future?

@OrlinVasilev
Copy link
Member

@steven-zou @nlowe is that valid or we can close? thank you!

@OrlinVasilev OrlinVasilev added the proposal/backlog Temporary archived proposals to be reviewed in the future! label Mar 20, 2023
@OrlinVasilev OrlinVasilev reopened this Mar 20, 2023
@OrlinVasilev OrlinVasilev requested review from a team as code owners March 20, 2023 11:14
@Razniak
Copy link

Razniak commented May 10, 2023

Hello, this case is still alive? :)

@OrlinVasilev
Copy link
Member

I think we can park this one for now.... as nobody is working on it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/core-services Related with core services kind/proposal proposal/backlog Temporary archived proposals to be reviewed in the future! status/reviewing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants