Mark 'operator workload continues running after catalog source is deleted' test as flaky#3746
Mark 'operator workload continues running after catalog source is deleted' test as flaky#3746tmshort wants to merge 1 commit intooperator-framework:masterfrom
Conversation
…eted' test as flaky
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
|
There was a huge effort to mark existing tests as "flake" a while back, to assuage the immensely painful (from dev's POV, I don't think we should be adding on to that anymore. I'm looking at #3737, and I don't understand why that test HAD to be added. What do we loose if we revert that PR for now since this test is flaking? |
@camilamacedo86 added the test recently because we're removing a catalog, and we needed a test for it. She will be looking at it soon. In the meantime, short of reverting #3737, this is the best solution. |
|
Oh looks like I had the same question on that PR too and there was an answer but I didn't get a chance to get around to the discussion. The "workload" you get when an operator is installed is handled by a different controller responsible for reconciling the ClusterServiceVersion CRs (olm-operator), than the one responsible for reconciling the catalogs (catalog-operator). This doc outlines that info https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/architecture.md#architecture ie I'm trying to make the case that "when a catalog is removed, the CSVs are untouched" is an axiom |
|
Possibly defer to #3747 |
The test has been failing pretty consistently since its introduced in #3737