Goals

• Reduce the number of snowflakes to maintain the Logging addon
• Setup CI/CD for the logging addon
• Introduce dependency to CLO builds that are already being created as part of existing CPaaS pipelines

Non-Goals

• This change makes no effort to resolve the issue where the CLO can be installed via OLM normal UI workflow an the add-on workflow.

Motivation

• Reduce logging team maintenance burden by reusing existing builds
• Align add-on deployment with managed tenants practices

Alternatives

Acceptance Criteria

• Logging add-on delivered as part of the add-on workflow that deploys CLO built from existing CPaaS pipelines

Risk and Assumptions

• Risk consumers of the add-on do not get the latest bug fixes to CLO because of the current packaging mechanism

Documentation Considerations

• Add developer documentation to remove compartmentalized knowledge
• Document the issue related to multiple paths of deploying CLO

Open Questions

What do upgrades look like after moving to an umbrella operator that depends upon CLO?

CLO ships in the redhat operator catalog which means it is possible CLO can be installed via the OLM workflow or the add-on workflow. Additionally, CLO is designed as a singleton because of the nature of the operands it controls. It is not clear to me how managed tenants will control specific version of the CLO if the subscription is following a channel; automatic subscriptions will auto-upgrade the CLO whenever a new version is available in the RH catalog. Is this acceptable experience for managed tenants?

Additional Notes

• addon config will likely continue to live in the CLO addon/managed-tenants repo
• MOLO will likely be delivered using the "cluster-logging" package that is currently in use by CLO to facilitate the upgrade path