Depreciate ErrNoOperatorCondition

[awgreene]

Problem: The ErrNoOperatorCondition does not surface any errors
encountered when retrieving OperatorConditions from the cluster.
It is not possible to know if there is an RBAC issue, if the
resource does not exist, or some other error.

Solution: Surface the error retrieving the OperatorCondition

[coveralls]

Pull Request Test Coverage Report for Build 1008560611

• 2 of 2 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 79.187%

---

Totals
Change from base Build 1005607081:	0.0%
Covered Lines:	331
Relevant Lines:	418

---

💛 - Coveralls

[varshaprasad96]

/lgtm

[varshaprasad96]

/approve
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: varshaprasad96

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:

• OWNERS [varshaprasad96]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[joelanford]

Just a belated nit: Since we no longer return this error, I think we should do one more thing.
Either:

• Add a bit more the the Deprecated comment (and fix the misspelling so it shows up in IDEs) to explain that this error is no longer returned and users should always expect the more generic error from the client
• Just go ahead and remove it (we're not v1 in operator-lib yet, so breaking changes are alright).

[awgreene]

Just go ahead and remove it (we're not v1 in operator-lib yet, so breaking changes are alright).

+1

[awgreene]

@joelanford I created #66 to remove the ErrNoOperatorCondition.

[estroz]

A 3rd option: wrap the underlying error in ErrNoOperatorCondition, which is my preference.

[awgreene]

@estroz what value did we get from the ErrNoOperatorCondition error?

[estroz]

I don't know, I was assuming there was a particular reason it was added in the first place. If you don't think there is benefit, then I'm in favor of removing the error entirely.

[joelanford]

It seems like the intention was to signal not found, but I agree with @awgreene's premise that:
a) it was swallowing and translating non-non found errors, which could give callers an incorrect impression
b) callers can just use apierrors.IsNotFound() to test the equivalent of what ErrNoOperatorCondition seems like it was meant to convey.