ci-operator/jobs/openshift/cluster-version-operator: Move master presubmits to GCP #10046
Conversation
openshift-ci-robot
added
the
approved
Can we continue |
How often do you use a CVO UPI presubmit to check that metric? I expect anyone concerned about it can use a promotion informer. Or launch a job with cluster-bot. But searching in the CVO repo and popping open the merge-time report on run presubmits, this job seems to have only ever been used in openshift/cluster-version-operator#319 (merged Feb. 12) and openshift/cluster-version-operator#332 (merged Feb. 28). And again, if I'm wrong, it's easy to add it back. |
|
I'm in favor of switching entirely to gcp. I don't have an opinion on whether or not we should keep the optional upi test, i see no jobs in prow history today but that doesn't mean it's without value. I don't think we should change the name to drop the cloud provider, those are uniform across almost all presubmits as far as I'm aware and provides immediate context to anyone looking at job names. |
So for all releases back through 4.1? Can you explain why you want a single platform across all releases?
I disagree that we need this context, or that if we need it we should get it from the job name. But I'll reroll to punt for this PR and file a follow-up with generic names where we can kick that around. |
Sorry, I just meant I'm in favor of the change you're making but I'd also be in favor of switching 4.5 and 4.4 too. The number of clusters we start on AWS is really high and CVO is quite isolated from platform so it seems like we're easy to move. Even over the weekend we had 50 AWS, during the week we're maxed out 12 hours a day. |
We don't need this context, but it's the norm for all jobs that provision clusters and we should follow the norm. |
…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
wking
force-pushed
the
aws-capacity-move-to-gcp
branch
from
1ea50c8 to
7ee21db
Compare
|
@wking: The following tests failed, say
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. DetailsInstructions 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. |
|
/retest |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: LalatenduMohanty, wking 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 |
|
@wking: Updated the following 15 configmaps:
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. |
…p -> e2e for 4.4+ In 7ee21db (ci-operator/jobs/openshift/cluster-version-operator: Move 4.4 and later presubmits to GCP, 2020-07-02, openshift#10046), I'd mentioned generic names as a way for component teams to say "we don't care which platform, other folks can pick whatever they want to balance platform volume vs. capacity". Scott pushed back based on lack of precedent [1,2]. And we currently do rely on platforms in job-names for monitored success rates. But these are presubmits, and presubmits are noisy (e.g. if you pull-request some buggy code, your presubmits will fail, but the delivered product is not affected by your in-flight bugs). So in the presubmit case we are not constrained by job-name-based health reporting. And we run a lot of presubmit volume, so even if this approach only works in the presubmit case, it gives us a lot of rebalancing flexibility. Benefits for component teams (the CVO maintainers in the case of this commit) include not having to care about where their jobs get scheduled. And with the job names not changing during rebalances, they don't have to remember to /skip or /refresh or whatever, because Prow would understand that it's the same effective test regardless of the underlying platform. Benefits to rebalancing admins is that they don't have to ask component teams to opt-in at rebalance time. Teams can opt in with this pattern, and rebalancing admins can just search for e2e steps that do not include a platform slug in their 'as' config name. Generated by manually changing ci-operator/config/... and then running: $ make update [1]: openshift#10046 (comment) [2]: openshift#10046 (comment)
5 participants
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 updateI've make the names generic
e2eande2e-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.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 (#7125), where it was motivated by a desire to test thecluster_installermetric. Now that that metric is well-established, we can drop the option. And we can always regrow it if we need it again later.