From 002a50c1770b126ba423920ac6c3863ba1c5d6c5 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Thu, 24 Jan 2019 02:36:48 -0800 Subject: [PATCH] docs/dev/operators: Reorder assigned runlevels (machine API to 30, etc.) Catching up with openshift/cluster-machine-approver@67d2bbcb (Change run level to 09, 2019-01-21, openshift/cluster-machine-approver#12), openshift/cluster-openshift-apiserver-operator@5a15f36e (move openshift apiserver later in CVO payload, 2019-01-21, openshift/cluster-openshift-apiserver-operator#121) moving to 61, openshift/cluster-openshift-controller-manager-operator@b823879a (move openshift controller manager later in CVO payload, 2019-01-21, openshift/cluster-openshift-controller-manager-operator#61) moving to 63, openshift/machine-config-operator@4dd8b917 (mco/install: update mco run level to 30, 2019-01-21, openshift/machine-config-operator#331), and operator-framework/operator-lifecycle-manager@f0e86b8c (chore(deploy): change 30 prefix to 50, 2019-01-21, operator-framework/operator-lifecycle-manager#678). I'm not personally clear on the reasoning; I'd have expected the OLM entries to belong at the end of the queue, since they seem less central than the OpenShift core operators. In [1], David Eads says that nothing earlier than 70 should require OpenShift APIs. The Machine API and autoapprover entries had been added to the end of the queue in dcab5e4c (payload: Ignore files without yaml, yml, or json extensions, 2018-12-01, #64), but I don't see any discussion of that placement there. I'd also understood the 0000_ prefix to be a special case for where ordering is critical, with most operators landing without specific ordering after the key components had been addressed. I dunno how that squares with: $ oc adm release extract --from=quay.io/openshift-release-dev/ocp-release:4.0.0-0.1 --to=/tmp/manifests Extracted release payload from digest sha256:66cee7428ba0d3cb983bd2a437e576b2289e7fd5abafa70256200a5408b26644 created at 2019-01-15T04:04:22Z $ ls /tmp/manifests | wc -l 191 $ ls /tmp/manifests | grep -v '^0000_' image-references release-metadata it looks like *all* of our operators are setting the 0000_ prefix. [1]: https://github.com/openshift/cluster-openshift-controller-manager-operator/pull/61#issue-246347960 --- docs/dev/operators.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/dev/operators.md b/docs/dev/operators.md index e68535f32..4d8c079eb 100644 --- a/docs/dev/operators.md +++ b/docs/dev/operators.md @@ -75,12 +75,11 @@ Assigned runlevels - 05 - cluster-config-operator - 07 - Network operator - 08 - DNS operator -- 09 - Service signer CA -- 10-19 - Kube operators (master team) -- 20-29 - OpenShift core operators (master team) -- 30-39 - OLM -- 50 - Machine API -- 51 - Machine Autoapprover +- 09 - Service certificate authority and machine approver +- 10-29 - Kubernetes operators (master team) +- 30-39 - Machine API +- 50-59 - Operator-lifecycle manager +- 60-69 - OpenShift core operators (master team) ## How do I ensure the right images get used by my manifests?