SAP BTP service operator enables developers to connect Kubernetes clusters to SAP BTP accounts and to consume SAP BTP services within the clusters by using Kubernetes native tools.
Apache License 2.0
126
stars
52
forks
source link
feat: support customization for logger dev mode #406
If there is no issue related to your pull request - open one and assign yourself to it. If you're proposing a solution to an already opened issue - simply assign yourself to it.
Issue: https://github.com/SAP/sap-btp-service-operator/issues/405
Motivation
When the log from btp operator is sent to a log system, e.g. OpenSearch, it make sense to turn off the dev mode, so the format will be json - which is simpler to process as structured fields
Approach
Use the btp chart with custom values I'll set manager.logger_use_dev_mode to false, so the log will be created in json format
Pull Request status
[x] Implementation
Feel free to construct the checklist with whatever items seem most reasonable for your change. You could disassemble the Implementation part to even smaller separate checklist items if you're working on something big for example. But do make the effort to provide a checklist of some sort so that the core team as well as the community can have an idea about the progress of your Pull Request.
Third-party code
If you use third party code with your contribution such as, components, libraries, or snippets make sure to mention that.
Work in Progress label
For as long as development of your Pull Request is still ongoing you MUST label it with a wip label as well as prefix the name of the PR with [WIP].
Pull Request Template
Prerequisites
Motivation
When the log from btp operator is sent to a log system, e.g. OpenSearch, it make sense to turn off the dev mode, so the format will be json - which is simpler to process as structured fields
Approach
Use the btp chart with custom values I'll set manager.logger_use_dev_mode to false, so the log will be created in json format
Pull Request status
Feel free to construct the checklist with whatever items seem most reasonable for your change. You could disassemble the Implementation part to even smaller separate checklist items if you're working on something big for example. But do make the effort to provide a checklist of some sort so that the core team as well as the community can have an idea about the progress of your Pull Request.
Third-party code
If you use third party code with your contribution such as, components, libraries, or snippets make sure to mention that.
Work in Progress label
For as long as development of your Pull Request is still ongoing you MUST label it with a wip label as well as prefix the name of the PR with [WIP].
For example: [WIP] Service brokers API