POC: Replace operator ManifestWork with OperatorPolicy#170
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mkolesnik The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Quick and dirty proof of concept to explore what operator installation via OperatorPolicy would look like. Not production quality, just enough to validate the approach end-to-end on a dev environment. Replace per-cluster ManifestWorks for operator installation with the OCM governance policy framework's OperatorPolicy. Instead of creating a ManifestWork per cluster containing OLM Subscription, OperatorGroup, and Namespace manifests, the controller now creates a single Policy + Placement + PlacementBinding that distributes an OperatorPolicy to all clusters in the ClusterSet. Key changes: - Controller creates Policy/Placement/PlacementBinding/ ManagedClusterSetBinding instead of per-cluster ManifestWorks - Status reads Policy compliance per-cluster instead of ManifestWork feedback for installedCSV - Deletion sets OperatorPolicy to mustnothave and waits for compliance before cleaning up (last mesh only) - Multi-tenancy: shared Policy uses addon-level labels only, non-last mesh deletion leaves the Policy intact - Dev-env installs governance-policy-framework and enables OperatorPolicy on managed clusters - Cacerts ManifestWork path unchanged Limitations: - Single operator package (sailoperator) for all platforms - GW API conflict on OCP 4.19-4.21 documented as known limitation (fixed in 4.22+, see issue open-cluster-management-io/config-policy-controller#479) Signed-off-by: Mike Kolesnik <mkolesni@redhat.com>
mkolesnik
force-pushed
the
spike/operator-policy
branch
from
17f23e3 to
fc20d4c
Compare
|
|
||
| for cluster in "${CLUSTER1}" "${CLUSTER2}"; do | ||
| log "Enabling governance-policy-framework on ${cluster}" | ||
| on "${HUB}" "${CLUSTERADM}" addon enable --names governance-policy-framework --clusters "${cluster}" |
There was a problem hiding this comment.
What would be a workflow for RH customers who want to use our addon? They would have to manually enabled governance-policy-framework addon as prereq or it's enabled by default?
There was a problem hiding this comment.
From my research this should be on by default in ACM, with the rest or policy engine bits.
I didn't test it on OCP though so there might be surprises there..
2 participants
Quick and dirty proof of concept to explore what operator installation via OperatorPolicy would look like.
Not production quality, just enough to validate the approach end-to-end on a dev environment.
Replaces per-cluster ManifestWorks for operator installation with the OCM governance policy framework's OperatorPolicy.
Instead of creating a ManifestWork per cluster containing OLM Subscription, OperatorGroup, and Namespace manifests, the controller now creates a single Policy + Placement + PlacementBinding that distributes an OperatorPolicy to all clusters in the ClusterSet.
Key changes:
Limitations: