-
Notifications
You must be signed in to change notification settings - Fork 2.1k
MON-1693: Add periodics to verify clusters with UMW can be safely upgraded #19545
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
MON-1693: Add periodics to verify clusters with UMW can be safely upgraded #19545
Conversation
ca57926 to
edb6a77
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Existing step touching this ConfigMap:
$ git --no-pager grep cluster-monitoring-config ci-operator/step-registry/
ci-operator/step-registry/ipi/install/monitoringpvc/ipi-install-monitoringpvc-commands.sh: name: cluster-monitoring-configYou'll probably want both steps to try to be more clever about YAML parsing (via Python?) to manage just the settings that their step is about, instead of having each of them claiming complete ownership of the config and possibly stomping the other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, hmm, this one is critical for upgrades.
I'll use yq to add modifications
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need upgrade in the name, everything in this file is an upgrade. e2e-aws-umw
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to have upgrade to be in the prowjob name, without it folks may assume its an install job
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't the prow job get called ci-openshift-release-master-ci-4.7-upgrade-from-stable-4.6-e2e-aws-umw-upgrade, i.e. upgrade appears twice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay, sure. Renameing this
80ff9d7 to
2d38c08
Compare
|
Ready for review, this updates both steps to add modifications to a single manifest using |
|
/retest |
1 similar comment
|
/retest |
2d38c08 to
5189b37
Compare
ci-operator/step-registry/ipi/conf/user-workload-monitoring/OWNERS
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can we use JSON / jq for the manifest, so we don't have to curl-install yq?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that would hamper the readability - and we've already settled on yaml manifests in most steps. Some other steps are pulling yq too, so I guess its "canon" now :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the config.yaml property is a string, right? Is yq smart enough to say "ah, the body of this string is also YAML, let me parse as YAML and add the new keys..."?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, it merges keys as YAML. Let me add a step to setup PVC for these jobs too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I was wrong, we have to extract it ourselves:
e890f37 to
e09a85d
Compare
|
/retest |
0e877f1 to
8075c0b
Compare
8e49c0a to
01c769a
Compare
1ceb57a to
451d7f7
Compare
ci-operator/step-registry/ipi/OWNERS
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to drop TRT in here, or one level up to cover the whole step registry?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to keep it here. We can rearrange owners when TRT is ready to handle the whole step registry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: seems like holding the patch in the shared directory is traditional, but I don't see why we'd ever want to share patches. I've filed #20865 to fix our existing use-cases, so you should be able to fix this without worrying about diverging from the pattern ;).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, fixed
wking
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just the two nits I mentioned above, and I'm fine if those get punted on. I'm also not an approver for the release jobs, so:
/lgtm
and there's time to circle back and address the nits if you want before we can get a release-job approver over to approve this.
451d7f7 to
7e13e21
Compare
7e13e21 to
13a30eb
Compare
These periodics would help us catch issues like https://bugzilla.redhat.com/show_bug.cgi?id=1953518
d184a73 to
5f73bc5
Compare
This step would ensure cluster is configured with user workload monitoring feature enabled
5f73bc5 to
7ef62d8
Compare
|
@vrutkovs: The following tests failed, say
Full PR test history. Your PR dashboard. 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. |
wking
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
|
/approve /lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cheesesashimi, vrutkovs, 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 |
|
@vrutkovs: Updated the following 3 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. |
These periodics would help us catch issues like https://bugzilla.redhat.com/show_bug.cgi?id=1953518