-
Notifications
You must be signed in to change notification settings - Fork 25
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
Access logs API proposal #624
Comments
/assign |
Created ADR based on proposal: #641 |
I think we can provide more information about why this is relevant in the Context. We already have a lot of information in the description of this issue that we can use. The decision only mentions handling of
As far as I understand this would only support the scenario of replacing the existing logFormat with your own format. How do we support only the update of single labels or adding a new custom label? Additionally, we should list a consequence that we allow the user to completely change the default access log. This means if we want to investigate an issue by enabling access logs for stdout, we might not all the labels that we need. This means we need to apply an EnvoyFilter to enable additional access logs with the log format that we might need. |
/cc @videlov |
User Scenario:
Decision:
config:
accessLog:
labels:
tenant: "" this should be valid right?
Examples:
Open:
|
I didn't know that. Can you provide how Istio manages the reconciliation of the extension providers with example how it's working? I've only found references that they are configured in IstioOperator CR.
Yup, correct. That is supposed to be for both of the loggers.
That is also correct. I only suspect that the providers will be referenced by name in the code. For te ADR scope I decided to reference them by type.
Yes, then the tenant value will be empty. Default values are only applied when
That is also correct. I only suspect that the providers will be referenced by name in the code. For te ADR scope I decided to reference them by type.
The values will be injected by istio based on envoy markers. If you want hands-on example then sure I will update the doc.
I proposed an example implementation. It's up to the developer implementing the feature.
Completely different structure. Please refer to the official Istio MeshConfig documentation. |
ADR is updated and accepted |
@Ressetkk: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Description
Based on POC that was already done propose enhancement to Istio API to allow user to configure access logs format. User should be able to provide key value map for format. In addition user should set strategy how format will be applied to default configuration.
ACs:
Reasons
User should be able to configure access log format that suits his requirements
DoD:
- [ ] Provide unit and integration tests.- [ ] Verify if the solution works for both open-source Kyma and SAP BTP, Kyma runtime.- [ ] If you changed the resource limits, explain why it was needed.- [ ] Verify that your contributions don't decrease code coverage. If they do, explain why this is the case.- [ ] Add release notes.Attachments
#489 (comment)
part of: #489
ADR: #641
The text was updated successfully, but these errors were encountered: