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
List only installed Operators; some refactor #4202
List only installed Operators; some refactor #4202
Conversation
@mik-dass @girishramnani @adisky @kadel in this PR, I've made some refactor to:
It's not a full refactor. I've only changed the bits that I needed to for this PR. |
@dharmit Shouldn't we add tests for the mentioned functionality in description on minikube. |
@prietyc123 yes we must. I'm inclined towards adding unit tests and not too much of integration tests. For that, I think, testing |
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
@prietyc123 the failure looks weird. It's not able to evaluate the regex that we're using to fetch the name of etcd Operator. On my CRC setup, I faced the same error for master branch!
It's executing the command |
c4bec97 should hopefully fix the issue. It worked for me on CRC. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kadel 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 |
/retest |
/retest Seeing unrelated failures:
|
Codecov Report
@@ Coverage Diff @@
## master #4202 +/- ##
==========================================
+ Coverage 42.23% 42.54% +0.31%
==========================================
Files 155 156 +1
Lines 13204 13267 +63
==========================================
+ Hits 5577 5645 +68
- Misses 7020 7021 +1
+ Partials 607 601 -6
Continue to review full report at Codecov.
|
/lgtm |
Test fails in the /test v4.5-integration-e2e |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
13 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
This increased timeout makes sure that `odo catalog list services` being executed in `JustBeforeEach` gets enough time to check for existence of two Operators that we're installing in CI to perform our checks. We need to increase this timeout because it's taking a long time for `odo catalog list services` to find "successfully installed" Operators in the newly created namespace even if these Operators are installed at cluster level, i.e., in the `openshift-operators` namespace. The increase in the time taken by odo to find this info is mainly attributed to #4202. I am observing that even `kubectl get csv` is taking more than usual time to list the Operators or report their phase as "Succeeded" but there's not enough data to back that up. So, in the interim, this seems like best way to make sure that CI doesn't keep failing on `JustBeforeEach`.
What type of PR is this?
/kind bug
/kind code-refactoring
What does does this PR do / why we need it:
This PR makes sure that odo lists only those Operators that are successfully installed. This success is determined on the basis of the
Phase
of Operator. If the phase evaluates toSucceeded
, the Operator is considered available to use.Which issue(s) this PR fixes:
Fixes #4155 & https://bugzilla.redhat.com/show_bug.cgi?id=1889961
PR acceptance criteria:
Unit test
Integration test
Documentation
I have read the test guidelines
How to test changes / Special notes to the reviewer:
This can be better tested on a minikube setup.