OPRUN-4459,OPRUN-4460: Remove dependency in OCP catalog content#642
OPRUN-4459,OPRUN-4460: Remove dependency in OCP catalog content#642camilamacedo86 wants to merge 1 commit intoopenshift:mainfrom
Conversation
|
@camilamacedo86: This pull request explicitly references no jira issue. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: camilamacedo86 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/hold They might able to release soon |
|
@camilamacedo86: all tests passed! 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-sigs/prow repository. I understand the commands that are listed here. |
|
/hold cancel |
| }) | ||
|
|
||
| // Keeping this test as skip:disconnected, so we can attempt to install a "real" operator, rather than a generated one | ||
| // There is an equivalent in-cluster positive test below |
There was a problem hiding this comment.
This seems to indicate that we already have an "in-cluster positive test"?
Does that mean we would simply delete this test? If not, what is the difference between the updated version of this test and the "equivalent in-cluster positive test below"?
There was a problem hiding this comment.
Most of our tests need to install a solution. But we don’t have another test that only checks the install step.
Right now, I would not in favor of remove this test because it affects our component readiness signal. We can think about removing it in the next cut branch, but not in this branch (we are too close).
So IMO we have these options:
-
A) Merge this PR. This removes the same pain we have every OCP release, and we keep a basic smoke test that can help when we need to isolate issues.
-
B) Close this PR now and reopen it after the new branch. Then we can propose removing the test 100% and handle any readiness-signal impact over time.
-
C) Do nothing. Keep everything as it is and coordinate this content for every OCP release cut.
There was a problem hiding this comment.
But we don’t have another test that only checks the install step.
To me this isn't that compelling of an argument on its own.
I would not in favor of remove this test because it affects our component readiness signal.
That is a compelling argument. And I think doing it now means one fewer release branch where we are exposed to the possibility that future catalog change can break this test.
I think my vote would be to merge this now, and then revisit after branch cut to see if it makes sense to reduce our test footprint if this test provides no extra coverage.
|
@camilamacedo86: This pull request references OPRUN-4459 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. This pull request references OPRUN-4460 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
| // Keeping this test as skip:disconnected, so we can attempt to install a "real" operator, rather than a generated one | ||
| // There is an equivalent in-cluster positive test below | ||
| // Uses the in-cluster built bundle (catalogdata + operatordata). Standalone; does not rely on Red Hat index. | ||
| var _ = Describe("[sig-olmv1][OCPFeatureGate:NewOLM][Skipped:Disconnected] OLMv1 operator installation", func() { |
There was a problem hiding this comment.
Are we able to drop [Skipped:Disconnected]?
Or does that affect the test name matching that component readiness does?
There was a problem hiding this comment.
We could remove it.
However, if we remove it now, we will change the test name/ID, and that will affect the component readiness signal.
So I suggest we review this after the branch cut.
After the cut:
- If we want to remove the test, we can remove it fully and we won’t need to create a new ID just to remove the skip.
- If we want to keep the test, then we remove the skip and follow the steps to deprecate this name and have the new ID test/signal
No description provided.