Open gaktive opened 4 years ago
This may be harder than we thought, so we may need a feature to make this easy for the admin.
After looking into this, I don't think it's fair to the platform operator to have to dig through all the bosh specs to find (and "translate") the dozens of settings required throughout all the jobs which would need to be set under properties:
in the values. This should be fixed in the helm chart instead, and we should expose a global logging_level value (which could then be overridden with specific properties:
settings when required for debugging).
This may be harder than we thought, so we may need a feature to make this easy for the admin.
It is not actually hard, it is mostly cumbersome. It mostly requires documentation of the settings you want to change.
If you want "a feature" you will still need to specify what the feature is supposed to do, which would be pretty much the same as creating the documentation.
There are bosh properties available in the upstream docs on how to set the logging level of various CF components: https://docs.cloudfoundry.org/running/managing-cf/logging.html
In scf, this was done easily -- the log level was configured through the
scf-config-values.yaml
file by using theLOG_LEVEL
property found in theenv:
section, which is then a property mapped to component-specific levels: https://documentation.suse.com/suse-cap/1.5.2/single-html/cap-guides/#sec-cap-log-levelsFor kubecf, we need to document how to translate the BOSH property settings into what we can interpret. The tricky part is that the logging parameters are very granular, so we need an easy way to toggle on a default setting and then allow people to modify individual settins as need be.
I'm not sure if we have to consider inputs for app logging: https://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html