Skip to content

mco/install: update mco run level to 30 #331

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
openshift-merge-robot merged 1 commit into from
Jan 21, 2019
Merged

mco/install: update mco run level to 30 #331

openshift-merge-robot merged 1 commit into from
Jan 21, 2019

Conversation

@kikisdeliveryservice
Copy link
Contributor

@kikisdeliveryservice kikisdeliveryservice commented Jan 21, 2019 •
edited
Loading

Update MCO run levels from 50 to 30.

cc: @abhinavdahiya

@openshift-ci-robot openshift-ci-robot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Jan 21, 2019
@abhinavdahiya
Copy link
Contributor

abhinavdahiya commented Jan 21, 2019

/lgtm

/cc @smarterclayton

@openshift-ci-robot openshift-ci-robot added lgtm Indicates that a PR is ready to be merged. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Jan 21, 2019
@jlebon
Copy link
Member

jlebon commented Jan 21, 2019

This really needs some more context. E.g. issue number, bug reports, or just simply answering in the commit message what this is fixing.

@ashcrow
Copy link
Member

ashcrow commented Jan 21, 2019

/test e2e-aws

@ashcrow
Copy link
Member

ashcrow commented Jan 21, 2019

@jlebon this was a request by @smarterclayton in chat.

@kikisdeliveryservice
Copy link
Contributor Author

kikisdeliveryservice commented Jan 21, 2019

/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 21, 2019
@kikisdeliveryservice
update mco run level to 30
4dd8b91 
change run level from 50 to 30 to match new ordering:
10-29 - kube control plane
30 - machines
50 - olm
60 - openshift control plane
70 - all other operators
@openshift-ci-robot openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Jan 21, 2019
@kikisdeliveryservice
Copy link
Contributor Author

kikisdeliveryservice commented Jan 21, 2019 •
edited
Loading

I updated the commit message to give more info to our future selves. 😄

@jlebon @ashcrow

@kikisdeliveryservice
Copy link
Contributor Author

kikisdeliveryservice commented Jan 21, 2019

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 21, 2019
@jlebon
Copy link
Member

jlebon commented Jan 21, 2019

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 21, 2019
@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Jan 21, 2019

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abhinavdahiya, jlebon, kikisdeliveryservice

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:
  • OWNERS [abhinavdahiya,jlebon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@wking
Copy link
Member

wking commented Jan 21, 2019

Cross-linking operator-framework/operator-lifecycle-manager#678 and openshift/cluster-openshift-apiserver-operator#121, which are also part of this manifest-order shuffle.

@wking
Copy link
Member

wking commented Jan 21, 2019

e2e-aws:

fail [github.com/openshift/origin/test/extended/deployments/deployments.go:215]: Expected error:
    <*errors.errorString | 0xc420095570>: {
        s: "timed out waiting for the condition",
    }
    timed out waiting for the condition
not to have occurred

failed: (39.3s) 2019-01-21T20:34:41 "[Feature:DeploymentConfig] deploymentconfigs when run iteratively [Conformance] should immediately start a new deployment [Suite:openshift/conformance/parallel/minimal]"

/retest

@openshift-merge-robot openshift-merge-robot merged commit 8e01f05 into openshift:master Jan 21, 2019
wking added a commit to wking/cluster-version-operator that referenced this pull request Jan 24, 2019
@wking
docs/dev/operators: Reorder assigned runlevels (machine API to 30, etc.)
52cf8bc 
Catching up with
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/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.

The Machine API and autoapprover entries had been added to the end of
the queue in dcab5e4 (payload: Ignore files without yaml, yml, or
json extensions, 2018-12-01, openshift#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.
@wking wking mentioned this pull request Jan 24, 2019
Merged
wking added a commit to wking/cluster-version-operator that referenced this pull request Jan 24, 2019
@wking
docs/dev/operators: Reorder assigned runlevels (machine API to 30, etc.)
6a6b3f6 
Catching up with
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/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.

The Machine API and autoapprover entries had been added to the end of
the queue in dcab5e4 (payload: Ignore files without yaml, yml, or
json extensions, 2018-12-01, openshift#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.
wking added a commit to wking/cluster-version-operator that referenced this pull request Jan 24, 2019
@wking
docs/dev/operators: Reorder assigned runlevels (machine API to 30, etc.)
5e25ae3 
Catching up with
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/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.

The Machine API and autoapprover entries had been added to the end of
the queue in dcab5e4 (payload: Ignore files without yaml, yml, or
json extensions, 2018-12-01, openshift#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.
wking added a commit to wking/cluster-version-operator that referenced this pull request Jan 24, 2019
@wking
docs/dev/operators: Reorder assigned runlevels (machine API to 30, etc.)
c02052c 
Catching up with
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 dcab5e4 (payload: Ignore files without yaml, yml, or
json extensions, 2018-12-01, openshift#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]: openshift/cluster-openshift-controller-manager-operator#61 (comment)
wking added a commit to wking/cluster-version-operator that referenced this pull request Jan 24, 2019
@wking
docs/dev/operators: Reorder assigned runlevels (machine API to 30, etc.)
002a50c 
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 dcab5e4 (payload: Ignore files without yaml, yml, or
json extensions, 2018-12-01, openshift#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]: openshift/cluster-openshift-controller-manager-operator#61 (comment)
@kikisdeliveryservice kikisdeliveryservice deleted the mco-run-level-30 branch February 6, 2019 20:59
osherdp pushed a commit to osherdp/machine-config-operator that referenced this pull request Apr 13, 2021
@openshift-merge-robot
Merge pull request openshift#331 from multi-arch/is-jenkins-agent-base
89a2a34 
Bug 1886890: Override jenkins-agent-base imagestream
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@abhinavdahiya abhinavdahiya Awaiting requested review from abhinavdahiya

@ashcrow ashcrow Awaiting requested review from ashcrow

@smarterclayton smarterclayton Awaiting requested review from smarterclayton

Assignees

@abhinavdahiya abhinavdahiya

@jlebon jlebon

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@kikisdeliveryservice @abhinavdahiya @jlebon @ashcrow @openshift-ci-robot @wking @openshift-merge-robot