Epic Goal

• Support create a global policy or application to use placement

Why is this important?

• Placementrule will be deprecated in the future. we need to switch to use placement
• Placement concept is used to dynamically select a set of managed clusters in one or multiple ManagedClusterSet. We can do some level RBAC to leverage managedclusterset.

Scenarios

1. On GH you can create a ManagedClusterSet with the label you want to use for access to clusters
2. On GH you can bind a user to the ManagedClusterSet
3. We can sync/replicate the ManagedClusterSet to all Region hubs
4. This way, when a user creates Placement, a webhook on Hoh can validate the user has access to the ManagedClusterSet. If access is TRUE, then the placement can be created, and it as well as the Policy or AppSub are propagated to the region clusters, where placement will use the LOCAL ManagedClusterSet to validate access and apply to the ManagedClusters matching placement.

Acceptance Criteria

• 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>