Epic Goal

• QE test validation that ACM can run properly on SNO.

Why is this important?

• ACM should be able to run properly on SNO (single node OpenShift).
• Many customers have requested this function.
• This is key for developers that want a live running ACM hub environment on small footprint.
• This is also heavily requested in the telco and edge markets.

Scenarios

1. An existing SNO.
2. Deploy ACM hub operator.
3. Verify all of the ACM capabilities work, eg, create new clusters, import and manage existing clusters, observability, grc policy, app.
4. Verify that the ACM on SNO can manage itself.
5. Ensure that the ACM on SNO can be upgraded: both the OCP version of the SNO itself, as well as the ACM hub operator.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• This should work with disconnected environments.
• This should work with Ipv4/Ipv6 dual stack.
• This should work with proxy enabled environments.

Dependencies (internal and external)

Previous Work (Optional):

1. HA SNO could be an interesting related topic in the context of ACM hub on SNO: 
   Recording: https://drive.google.com/file/d/1gLZR84tigPOOWJpo97sbTUJa4d5rLq8X/view?usp=sharing
   Jira Epic:   https://issues.redhat.com/browse/ECOPROJECT-13
   Code:        https://github.com/mshitrit/hasno-setup-operator/tree/ha_operator
   Setup:        https://docs.google.com/document/d/1ae_nBm3ZnpYhEzNXYhgEQmfpWDpk6Bl5xhnIYPnUC7w/edit

Open questions:

1. When deploying ACM hub on SNO, should we disable hub self-management to prevent the user from accidentally crashing the hub?
2. When deploying ACM hub on SNO, should we disable the hub HA features?
3. When deploying ACM hub on SNO, do we need to document that this should not be used for production environments?

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>