Customer Problem: As an OpenShift admin running Quay I need to be able to do troubleshoot using the Quay application logs when there are issues. Ideally I would do this in the same way I troubleshoot all other OpenShift Add-Ons and keep all OpenShift and Add-on logs in a central location.

Goal: Quay leverages the OCP built-in logging capabilities

Problem:

• as of today customers can't use the OpenShift logging capabilities for Quay if Quay runs on OCP or one of the Quay operators (CSO, integration operator) runs there

Why is this important: 

• Extends the value of OpenShift using Quay
• Extends the value of Quay if used in conjunction with OpenShift
• avoids double-efforts of building our own logging solution

Dependencies (internal and external):

• OpenShift logging prerequisites

Prioritized epics + deliverables (in scope / not in scope):

• Ability to forward Quay action logs to OpenShift logging facility (e.g. ElasticSearch)
• Viewing of Quay action logs in ElasticSearch console / OpenShift's Kibana

Estimate (XS, S, M, L, XL, XXL):  TBD

Previous Work: 

• Logfile exporter (Quay 3.3 feature)
• Quay Elasticsearch efforts

Open questions:

• So far the OCP stack is based on Elasticsearch but might change over time (OCP 4.6+). Transition to future stack need to be considered as well  [Probably OCP 5 timeframe]
• Since we can't assume that Elasticsearch runs on every OCP cluster (not all OCP customers are using it), can we autodetect whether it's there or not or do we leave it up to the user to switch it on only if backend dependencies are satisfied?
• Do we want to create our own ElasticSearch instance (using the ES Operator)?
• Any security concerns with us using Cluster Logging for action logs?
• Would a log forwarding solution create a bigger customer value and should we focus on this instead?