-
Notifications
You must be signed in to change notification settings - Fork 63
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
fix: remove call to legacy template validator #613
fix: remove call to legacy template validator #613
Conversation
Hi @nestoracunablanco. Thanks for your PR. I'm waiting for a kubevirt member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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-sigs/prow repository. |
Strange, that looks a bit dangerous to me. Is SSP even present on the cluster? In any case, it shouldn't be using the standalone virt-template-validator, which has been deprecated for a long time. @ksimon1 Please advise |
@0xFelix is correct, we should not use the standalone template validator. |
aa7492f
to
a9be1ce
Compare
@ksimon1 I made one change. Could you please check if it aligns with your intention? |
automation/test.sh
Outdated
oc apply -n kubevirt -f ${VALIDATOR_DIR} | ||
oc wait --for=condition=Available --timeout=${timeout}s deployment/virt-template-validator -n $namespace | ||
git clone -b ${SSP_VERSION} --depth 1 https://github.com/kubevirt/ssp-operator ssp-operator | ||
make -C ssp-operator deploy |
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.
Can you make sure this will not enable deployment of common-templates
in SSP? IIRC in its default configuration it will enable the deployment which could clash with the common-templates deployed by this test.
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.
AFAIR templates from this repo are deployed in kubevirt namespace, so there should be no conflict in templates.
I would not clone the ssp repo, but deploy it directly from manifests, because this clone will anyway deploy only released version
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.
@ksimon1: done
The template validator code has been moved to the ssp-operator repository. As a result, we need to deploy the SSP Operator to ensure that the templates do not contain any errors in the validation rules. Signed-off-by: Nestor Acuna Blanco <nestor.acuna@ibm.com>
a9be1ce
to
9486277
Compare
/ok-to-test |
/retest |
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.
Looks good to me. Thanks!
/approve
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 0xFelix, ksimon1 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 |
The template validator code is now located in the ssp-operator repository. To deploy the validator exclusively, additional changes are required in the ssp. However, experimentation indicates that these changes are not necessary for the end-to-end tests to function properly.
What this PR does / why we need it: s390x enablement
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
Release note: