Improve Operator API Status

[pgodowski]

Based on #162 there is introduced .spec.version in Operator API - but I think we also need to indicate what's the resolved version actually running.

So - I think we need to have some status fields indicating the actually resolved version and the actually running version of the operator.

---

We'll be using this ticket to track the associated work as we address it in 0.2.0

Demo Script

1. To be continued

Related Issues:

• Add status.installedBundleSource #199
• Add status.resolvedBundleSource #202
• Changing our condition types to include Installed and Resolved. #200
• Removing or re-defining the meaning of the existing Ready condition. #201

[tlwu2013]

One additional/similar use case @anik120 brought up during the demo:
when resolve failed but the currently installed version is still running well from the previously resolved version.

In the demo, users would need to check BundleDeployment to tell this, it'll be better if this can be better surfaced to the Operator API.

[tlwu2013]

@joelanford

I think I heard:

1. Status.installedVersion
2. Status.resolvedVersion
3. Split Ready Condition into installation status and resolution status

[joelanford]

I'd suggest splitting these into separate issues. Each of these sounds simple, but there's actually quite a bit of nuance.

For example, installed version is tricky:

• What do we set installedVersion to if we are unable to progress far enough during reconciliation to see what exists in the BD? (This points to the fact that we probably need an observedGeneration associated with this particular value, somehow)
• Even if we can see the BD, there's no guarantee that the information we see there will be something we can derive the version from.
  • A plain manifest bundle has no version metadata.
  • If we resolved that plain manifest bundle from a catalog that contained the version metadata, there's no guarantee that the catalog still contains the bundle such that we could do a reverse lookup.
• The BD doesn't even have to map back to a lookup-able source. It could have somehow gotten a spec.template.spec.source containing config maps or manifests from an upload.