Status

Dec 13

• Playback done

Nov 30

• Dev complete
• ready for playback

Nov 23

• Dev almost done
• Doc to be done this week as well
• ETA: End of sprint 22

Nov 1

• Making progress
• Implementation to be continued in sprint 21

Epic Goal

• Prototype scheduling hosted cluster placement to a set of hosting service clusters based on the current load (# of hosted clusters on the service cluster)
• prioritize managed cluster with most/least number of hosted control planes
• once a given managed cluster reaches a given number of hosted control planes (e.g. 80), exclude it from placement consideration altogether

https://open-cluster-management.io/concepts/placement/#extensible-scheduling 

Why is this important?

• Service Delivery is exploring how to efficiently distribute placement of hosted clusters on the available hosting service clusters

Scenarios

1. Service Delivery wants to place a hosted cluster on a hosting service cluster that has not met a specified maximum load count

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. Placement supports decision weighting (can be extended)
2. ClusterClaim and bring details about the number of HostedClusters on a Hosting Service Cluster back to ACM
3. Placement can be triggered via ClusterClaim values.

Open questions::

1. Do we need a controller on the Hosting Service Cluster to collect the counts and store them as a ClusterClaim
2. Can we use placement ClusterClaim selector with this?
3. Do we need a new weighting for placement on this topic
4. Can we determine the counts from the hub?

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>