Epic Goal

• Fully deprecate and remove gatekeeper-operator and associated ACM install policy no later than ACM-2.8
• Deliver new gatekeeper delivery through a helm-based ACM addon
• The gatekeeper helm-based ACM addon will deliver async from ACM releases and instead be validated with specific ACM releases
• Deliver container images in as-close-to fully automatic downstream as possible (auto-release freshmaker, etc.)

Why is this important?

• The gatekeeper-operator is out-of-sync with the upstream gatekeeper community pattern. The community primarily uses helm charts as the delivery mechanism. Switching to a helm-based ACM add-on would allow better support and alignment to Red Hat customers through community engagement.
• Gatekeeper releases much more frequently than ACM with significant enhancements and bug fixes; releasing the add-on async from ACM will mean better customer choice and experience.

Scenarios

1. ACM can make use of a helm-based ACM addon and perform policy inform/enforce via usual / existing methods

Acceptance Criteria

• CVP tests to validate functionality for auto-release of advisories (freshmaker, z-stream, etc.)
• Document migration from gatekeeper-operator to add-on
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. ...

Open questions::

1. ...

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>