Epic Goal

Resolve conflicting CRDs between MCE, Hypershift, and CAPI to ensure smooth coexistence of components, prevent constant reconciliation issues, and enable a better end-user experience. This includes implementing a solution that gives users control over CRD deployment, ideally preventing the installation of conflicting CRDs when certain components are enabled.

Why is this important?

Currently, CRD conflicts cause significant problems for users. When ACM or MCE share CRDs with other operators, such as Hypershift or CAPI, MCE can constantly re-reconcile and overwrite user changes. This prevents customization and leads to an unstable system. Resolving this issue will reduce user frustration, decrease the need for manual workarounds, and ensure the long-term stability and reliability of the platform.

Scenarios

...

Acceptance Criteria

• The MCE operator must not reconcile against CRDs that are not owned but are shared with other operators.
• A mechanism must be implemented to allow end-users to control CRD deployment to prevent conflicts.
• The solution must support conditional deployment of CRDs based on component enablement (e.g., using feature flags).
• For the 2.15 release, CAPI and CAPA must be disabled by default.
• Documentation must be updated to clearly explain the CRD conflicts and the recommended manual workarounds for the 2.15 release.
• The long-term solution must be scoped and sized for implementation in the 2.16 release.

Dependencies (internal and external)

1. Internal: MCE Operator, ACM.
2. External: Hypershift Operator, OpenShift Core Team (for CRD compatibility fixes)

Previous Work (Optional):

1. ...

Open questions:

1. What is the specific long-term technical solution for CRD management? Will it use annotations, feature flags, or another method?
2. How will the team handle the risk of automatically removing CRDs upon component disabling, especially given the need to preserve CRs?
3. How will the new CRD management logic be tested by QE to ensure it covers all scenarios, including component switching?

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 - Doc issue opened with a completed template. Separate doc issue
  opened for any deprecation, removal, or any current known
  issue/troubleshooting removal from the doc, if applicable.
• Considerations were made for Extended Update Support (EUS)