Bug 1797806: metrics: include upi installs in cluster_installer #319
Conversation
This is a follow-on to c147732, which added the cluster_installer series originally. Recently, the installer started injecting a new ConfigMap (openshift-install-manifests), which includes information about the manifest generation stage of the install. Because this phase always happens, this ConfigMap is included in every cluster created by this newer installer. We can now look at the presence of this new ConfigMap and the absence of the openshift-install ConfigMap to determine that the cluster was installed using UPI. We can additionally look at its contents to determine information about the installer.
openshift-ci-robot
added
approved
crawford
changed the title
openshift-ci-robot
added
the
do-not-merge/work-in-progress
|
/test e2e-aws-upi |
|
/test e2e-aws-upi |
|
/retitle metrics: include upi installs in cluster_installer |
openshift-ci-robot
changed the title
openshift-ci-robot
removed
the
do-not-merge/work-in-progress
|
/retitle Bug 1797806: metrics: include upi installs in cluster_installer |
openshift-ci-robot
changed the title
|
@crawford: This pull request references Bugzilla bug 1797806, which is invalid:
Comment DetailsIn response to this:
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. |
openshift-ci-robot
added
the
bugzilla/invalid-bug
crawford
added
bugzilla/valid-bug
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya, crawford 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 |
|
/cherrypick release-4.3 |
|
@abhinavdahiya: once the present PR merges, I will cherry-pick it on top of release-4.3 in a new PR and assign it to you. DetailsIn response to this:
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. |
|
@crawford: Bugzilla bug 1797806 is in an unrecognized state (VERIFIED) and will not be moved to the MODIFIED state. DetailsIn response to this:
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. |
|
@abhinavdahiya: new pull request created: #321 DetailsIn response to this:
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. |
…er presubmits to GCP AWS is currently at CI-capacity limits, so move over to GCP to get more elbow room. Generated by adjusting the config/ entry by hand and then running: $ make update I'd initially just shifted master, because the bulk of our CI is on master-targeted pulls. But Scott asked for 4.4 and later [1], so that's what I'm doing now. I'd like to move to generic names like "e2e" and "e2e-upgrade", because we don't care (from the CVO side) what platform these run on. Generic names will mean smaller diffs if we pivot the workflow and cluster_profile to a different provider in the future. But Scott is not (yet ;) ready to break with tradition here [2], so punting on that for now. I've dropped "e2e-aws-upi", because the CVO shouldn't care about that level of provisioning detail. We just need "a cluster". We've had the optional UPI job since ce9361b (cluster-version-operator: add aws-upi optional job, 2020-02-11, openshift#7125), where it was motivated [3] by a desire to test the cluster_installer metric [4]. Now that that metric is well-established, we can drop the option. And we can always regrow it if we need it again later. [1]: openshift#10046 (comment) [2]: openshift#10046 (comment) [3]: openshift#7125 (comment) [4]: openshift/cluster-version-operator#319
5 participants
This is a follow-on to c147732, which added the cluster_installer
series originally. Recently, the installer started injecting a new
ConfigMap (openshift-install-manifests), which includes information
about the manifest generation stage of the install. Because this phase
always happens, this ConfigMap is included in every cluster created by
this newer installer. We can now look at the presence of this new
ConfigMap and the absence of the openshift-install ConfigMap to
determine that the cluster was installed using UPI. We can additionally
look at its contents to determine information about the installer.