Skip to content

ci-operator/step-registry/manifests: Factor day-2 manifests into own step #8953

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.

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

Merged

Conversation

wking
Copy link
Member

@wking wking commented May 7, 2020

These have been part of the e2e test step since that step landed in a2fd8c3 (#6965). But pushing manifests is more of an install thing than a test thing. For example, if a user swaps in their own tests, we still want the cluster to push insights if their cluster profile includes the token).

The logic I'm replacing was just handling the insights operator. To allow us to recycle the same logic for additional manifests, I've carved out generic handling for ${CLUSTER_PROFILE_DIR}/manifests and ${SHARED_DIR}/manifests. There's a bit of hoop-jumping to build
DIRECTORIES, because oc apply -r -f ... chokes on empty directories:

$ mkdir /tmp/example
$ oc apply --recursive -f /tmp/example
error: error reading [/tmp/example]: recognized file extensions are [.json .yaml .yml]
$ oc version --client
Client Version: v4.2.0-alpha.0-275-g9d412f4

Ideally we'd update the cluster profiles themselves to store the config in manifests/insights-live.yaml (via a core-services/ci-secret-bootstrap/_config.yaml edit?). But we can't do that until we've removed or ported the old-style templates under ci-operator/templates, so I'm leaving that off for now and keeping a HACK check to copy the current profile's file into the newly-expected target location.

The previous logic also used an error-ignoring || true since at least b887d20 (#3951). That commit didn't motivate its use, so I'm dropping it here. If the step fails, figuring out the culprit should be pretty straightforward.

@wking wking force-pushed the separate-manifests-step branch 3 times, most recently from 96d9a98 to 990de82 Compare May 7, 2020 23:12
@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 10, 2020
@bbguimaraes
Copy link
Contributor

LGTM except we'll have to use files (manifest_*?) because CLUSTER_PROFILE_DIR and SHARED_DIR are (read-only) Secret mounts.

@wking wking force-pushed the separate-manifests-step branch from 990de82 to 78df4fc Compare July 1, 2020 19:13
@openshift-ci-robot openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 1, 2020
@wking wking force-pushed the separate-manifests-step branch from 78df4fc to da26f4f Compare July 1, 2020 19:14
@wking
Copy link
Member Author

wking commented Jul 1, 2020

LGTM except we'll have to use files (manifest_*?) because CLUSTER_PROFILE_DIR and SHARED_DIR are (read-only) Secret mounts.

manifest_(manifest_name).yml is already used for install. I've pushed 990de827d9 -> da26f4f772 pivoting to ${CLUSTER_PROFILE_DIR}/day-2-manifests-*.yaml and ${SHARED_DIR}/day-2-manifests-*.yaml and rebasing onto master.

…step

These have been part of the e2e test step since that step landed in
a2fd8c3 (step-registry: add Origin E2E test step, 2020-01-31, openshift#6965).
But pushing manifests is more of an install thing than a test thing.
For example, if a user swaps in their own tests, we still want the
cluster to push insights if their cluster profile includes the token).

The logic I'm replacing was just handling the insights operator.  To
allow us to recycle the same logic for additional manifests, I've
carved out generic handling for ${CLUSTER_PROFILE_DIR} and
${SHARED_DIR}.  The day-2 naming avoids conflicts with the ipi/install
step that is already consuming ${SHARED_DIR}/manifest_*.yml

Glob expansion should have stable ordering; from POSIX [1]:

  If the pattern matches any existing filenames or pathnames, the
  pattern shall be replaced with those filenames and pathnames, sorted
  according to the collating sequence in effect in the current locale.

Ideally we'd update the cluster profiles themselves to store the
config in day-2-manifests-insights-live.yaml (via a
core-services/ci-secret-bootstrap/_config.yaml edit?).  But we can't
do that until we've removed or ported the old-style templates under
ci-operator/templates, so I'm leaving that off for now and keeping a
HACK check to copy the current profile's file into the newly-expected
target location.

The previous logic also used an error-ignoring '|| true' since at
least b887d20 (Deploy the insights secret for the support-operator
in all templates, 2019-06-04, openshift#3951).  That commit didn't motivate its
use, so I'm dropping it here.  If the step fails, figuring out the
culprit should be pretty straightforward.

[1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03
@wking wking force-pushed the separate-manifests-step branch from da26f4f to 67cb826 Compare July 1, 2020 19:33
@openshift-ci-robot
Copy link
Contributor

@wking: The following tests failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
ci/rehearse/openshift/installer/master/e2e-vsphere 990de827d94b3be230c65b6d7ad4a220603831a6 link /test pj-rehearse
ci/rehearse/openshift/installer/master/e2e-gcp-upi 990de827d94b3be230c65b6d7ad4a220603831a6 link /test pj-rehearse
ci/rehearse/openshift/cluster-network-operator/master/e2e-aws-sdn-multi 990de827d94b3be230c65b6d7ad4a220603831a6 link /test pj-rehearse
ci/rehearse/openshift/cluster-network-operator/master/e2e-aws-sdn-single 990de827d94b3be230c65b6d7ad4a220603831a6 link /test pj-rehearse
ci/rehearse/openshift/cluster-network-operator/master/e2e-ovn-hybrid-step-registry 990de827d94b3be230c65b6d7ad4a220603831a6 link /test pj-rehearse
ci/rehearse/cri-o/cri-o/release-1.13/e2e-aws 990de827d94b3be230c65b6d7ad4a220603831a6 link /test pj-rehearse
ci/rehearse/openshift/cluster-network-operator/master/e2e-ovn-step-registry 990de827d94b3be230c65b6d7ad4a220603831a6 link /test pj-rehearse
ci/prow/pj-rehearse 67cb826 link /test pj-rehearse

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@bbguimaraes
Copy link
Contributor

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 2, 2020
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bbguimaraes, wking

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

The pull request process is described here

Needs approval from an approver in each of these files:

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

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 2, 2020
@openshift-merge-robot openshift-merge-robot merged commit b23bef2 into openshift:master Jul 2, 2020
@openshift-ci-robot
Copy link
Contributor

@wking: Updated the following 2 configmaps:

  • step-registry configmap in namespace ci at cluster api.ci using the following files:
    • key ipi-aws-pre-chain.yaml using file ci-operator/step-registry/ipi/aws/pre/ipi-aws-pre-chain.yaml
    • key ipi-azure-pre-chain.yaml using file ci-operator/step-registry/ipi/azure/pre/ipi-azure-pre-chain.yaml
    • key ipi-azure-pre-sharednetwork-chain.yaml using file ci-operator/step-registry/ipi/azure/pre/sharednetwork/ipi-azure-pre-sharednetwork-chain.yaml
    • key ipi-gcp-pre-chain.yaml using file ci-operator/step-registry/ipi/gcp/pre/ipi-gcp-pre-chain.yaml
    • key ipi-gcp-pre-sharednetwork-chain.yaml using file ci-operator/step-registry/ipi/gcp/pre/sharednetwork/ipi-gcp-pre-sharednetwork-chain.yaml
    • key ipi-vsphere-pre-chain.yaml using file ci-operator/step-registry/ipi/vsphere/pre/ipi-vsphere-pre-chain.yaml
    • key OWNERS using file ci-operator/step-registry/manifests/OWNERS
    • key manifests-commands.sh using file ci-operator/step-registry/manifests/manifests-commands.sh
    • key manifests-ref.yaml using file ci-operator/step-registry/manifests/manifests-ref.yaml
    • key openshift-e2e-aws-loki-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/loki/openshift-e2e-aws-loki-workflow.yaml
    • key openshift-e2e-aws-ovn-hybrid-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/ovn/hybrid/openshift-e2e-aws-ovn-hybrid-workflow.yaml
    • key openshift-e2e-aws-ovn-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/ovn/openshift-e2e-aws-ovn-workflow.yaml
    • key openshift-e2e-aws-sdn-multi-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/sdn/multi/openshift-e2e-aws-sdn-multi-workflow.yaml
    • key openshift-e2e-aws-sdn-single-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/sdn/single/openshift-e2e-aws-sdn-single-workflow.yaml
    • key openshift-e2e-azure-ovn-workflow.yaml using file ci-operator/step-registry/openshift/e2e/azure/ovn/openshift-e2e-azure-ovn-workflow.yaml
    • key openshift-e2e-gcp-loki-workflow.yaml using file ci-operator/step-registry/openshift/e2e/gcp/loki/openshift-e2e-gcp-loki-workflow.yaml
    • key openshift-e2e-test-commands.sh using file ci-operator/step-registry/openshift/e2e/test/openshift-e2e-test-commands.sh
    • key openshift-e2e-vsphere-ovn-workflow.yaml using file ci-operator/step-registry/openshift/e2e/vsphere/ovn/openshift-e2e-vsphere-ovn-workflow.yaml
    • key upi-gcp-pre-chain.yaml using file ci-operator/step-registry/upi/gcp/pre/upi-gcp-pre-chain.yaml
  • step-registry configmap in namespace ci at cluster app.ci using the following files:
    • key ipi-aws-pre-chain.yaml using file ci-operator/step-registry/ipi/aws/pre/ipi-aws-pre-chain.yaml
    • key ipi-azure-pre-chain.yaml using file ci-operator/step-registry/ipi/azure/pre/ipi-azure-pre-chain.yaml
    • key ipi-azure-pre-sharednetwork-chain.yaml using file ci-operator/step-registry/ipi/azure/pre/sharednetwork/ipi-azure-pre-sharednetwork-chain.yaml
    • key ipi-gcp-pre-chain.yaml using file ci-operator/step-registry/ipi/gcp/pre/ipi-gcp-pre-chain.yaml
    • key ipi-gcp-pre-sharednetwork-chain.yaml using file ci-operator/step-registry/ipi/gcp/pre/sharednetwork/ipi-gcp-pre-sharednetwork-chain.yaml
    • key ipi-vsphere-pre-chain.yaml using file ci-operator/step-registry/ipi/vsphere/pre/ipi-vsphere-pre-chain.yaml
    • key OWNERS using file ci-operator/step-registry/manifests/OWNERS
    • key manifests-commands.sh using file ci-operator/step-registry/manifests/manifests-commands.sh
    • key manifests-ref.yaml using file ci-operator/step-registry/manifests/manifests-ref.yaml
    • key openshift-e2e-aws-loki-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/loki/openshift-e2e-aws-loki-workflow.yaml
    • key openshift-e2e-aws-ovn-hybrid-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/ovn/hybrid/openshift-e2e-aws-ovn-hybrid-workflow.yaml
    • key openshift-e2e-aws-ovn-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/ovn/openshift-e2e-aws-ovn-workflow.yaml
    • key openshift-e2e-aws-sdn-multi-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/sdn/multi/openshift-e2e-aws-sdn-multi-workflow.yaml
    • key openshift-e2e-aws-sdn-single-workflow.yaml using file ci-operator/step-registry/openshift/e2e/aws/sdn/single/openshift-e2e-aws-sdn-single-workflow.yaml
    • key openshift-e2e-azure-ovn-workflow.yaml using file ci-operator/step-registry/openshift/e2e/azure/ovn/openshift-e2e-azure-ovn-workflow.yaml
    • key openshift-e2e-gcp-loki-workflow.yaml using file ci-operator/step-registry/openshift/e2e/gcp/loki/openshift-e2e-gcp-loki-workflow.yaml
    • key openshift-e2e-test-commands.sh using file ci-operator/step-registry/openshift/e2e/test/openshift-e2e-test-commands.sh
    • key openshift-e2e-vsphere-ovn-workflow.yaml using file ci-operator/step-registry/openshift/e2e/vsphere/ovn/openshift-e2e-vsphere-ovn-workflow.yaml
    • key upi-gcp-pre-chain.yaml using file ci-operator/step-registry/upi/gcp/pre/upi-gcp-pre-chain.yaml

In response to this:

These have been part of the e2e test step since that step landed in a2fd8c3 (#6965). But pushing manifests is more of an install thing than a test thing. For example, if a user swaps in their own tests, we still want the cluster to push insights if their cluster profile includes the token).

The logic I'm replacing was just handling the insights operator. To allow us to recycle the same logic for additional manifests, I've carved out generic handling for ${CLUSTER_PROFILE_DIR}/manifests and ${SHARED_DIR}/manifests. There's a bit of hoop-jumping to build
DIRECTORIES, because oc apply -r -f ... chokes on empty directories:

$ mkdir /tmp/example
$ oc apply --recursive -f /tmp/example
error: error reading [/tmp/example]: recognized file extensions are [.json .yaml .yml]
$ oc version --client
Client Version: v4.2.0-alpha.0-275-g9d412f4

Ideally we'd update the cluster profiles themselves to store the config in manifests/insights-live.yaml (via a core-services/ci-secret-bootstrap/_config.yaml edit?). But we can't do that until we've removed or ported the old-style templates under ci-operator/templates, so I'm leaving that off for now and keeping a HACK check to copy the current profile's file into the newly-expected target location.

The previous logic also used an error-ignoring || true since at least b887d20 (#3951). That commit didn't motivate its use, so I'm dropping it here. If the step fails, figuring out the culprit should be pretty straightforward.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants