Epic Goal

Maintain the existing customer facing Custom Resource interactions through the kubernetes API server (ACM as ACM)

Why is this important?

The existing customer base that relies on declarative architecture has become large and having both a Kube and Rest interface will allow us to gauge the benefits and usage of each. Having both interfaces with their usage metrics may help with upstream and managed decisions.

Scenarios

The following Custom Resources should still work with a Rest Inventory and Message Queue transport system:

1. ManagedCluster
2. ManagedClusterInfo
3. ManagedClusterView
4. ManifestWork
5. ManifestWorkReplicaSet

The following can remain as Custom Resource Definitions

1. Placement
2. PlacementBinding
3. PlacementDecision
4. Policy (all three types)
5. Application CRD's (those not deprecated or in maintenance mode
6. What is missing??

We can consider pulling Placement into the prototype

Acceptance Criteria

No disruption to existing customers, both API & Console, allowing GitOps flows to continue.

Dependencies (internal and external)

1. /api/cluster_mgmt/v2 is available
2. Maestro API's are available

Previous Work (Optional):

1. MCM did have an aggregated API server at one point

Open questions:

1. Continue to use CRDs and synchronize the status from the REST API
2. Develop an Aggregated API server extension for the 5 core CRDs

Done Checklist

• CI - CI can build an image to test the prototype
• Release Enablement The prototype is Accepted and a technical/developer preview is chosen
• DEV - Stolostron code and tests merged.
• DEV - Stolostron documentation merged.
• QE - Test plan discussed.