1. Proposed title of this feature request
Cluster wide logging configuration
2. What is the nature and description of the request? 
The customer would like a means by which to control the logging levels of each component such that they can reduce the logging verbosity of various components through a central contol. Various Operators log at varios different levels (some debug by default) and this has an impact on both the consumed CPU cycles spent doing the logging activity and then filtering said logs, as well as the storage requirements for off cluster logging services like Splunk.
3. Why does the customer need this? (List the business requirements here)

Customer described the problem as follows:
The volume of logged messages is very high. On investigation, this is because the logging level for containers in the core product and operators appears to be set at the Information or Debug level. This creates a number of challenges:

• Wasting resource. Each record cut uses CPU and memory. If not filtered by the logging operator - which itself uses resources to do this - the records must be written to storage.
• Cost. The cost of storing all of this data is significant. In common with a lot of businesses, we make extensive use of Splunk as a common logging target. This provides all of the log information in a single solution, but charging is based on the volume of data delivered to the platform each day. It is immensely frustrating when most of this is worthless.
• Usability. If we need to look at a problem, the volume of data means that it is difficult to track down the warning and error messaging in the lake of debug messaging.

We would hope that it would be relatively simple to apply a configurable cluster wide default logging level. This could then be overridden if there was a need for more detailed information to support diagnosis. The alternative is to simply filter out everything that we don't need in the logging operator. As mentioned above, this means that resources are used to generate a large volume of operationally worthless data that is then removed by further resource consumption, so is not optimal.

4. List any affected packages or components.

All core OpenShift Operators and components.