Goal: As an operator maintainer I want customers installing my operator to know which operand / product versions the operator will install so that i can dissociate the operator version from the operand version and release operator-specific patches that don't make product-level implications as well as expose this data to dependency resolution.

Background: Today it's possible to version the Operator as in the controller software as well as the APIs (CRDs) through which it is exposed to users. This information is being used in as input to the the resolver in OLM to pick the right Operator dependencies (OLM-1408). However there is no information exposed which versions of the managed workload is actually provided by an Operator. The information about the Operand alone however is usually not enough for dependency resolution as an Operator not only know which Operator can provide a certain Operand but it also needs to know it interacts with the Operator to request it. So Operand version constraints are likely going to be used in conjunction with other constraints, like APIs or Operator version.

Why is this needed: Example: a DBaaS Operator can likely manage multiple versions of MySQL. If a user needs a particular version, say MySQL 5.7 they need to manually research if the DBaaS Operator supports that and if so, starting or ending with which version. If another Operator, say an AppOperator depends on the DBaaS Operator to provide a MySQL 5.7 database there is no way to express this dependency today, because the information about the version range of MySQL releases the DBaaS Operator understands is not exposed through Operator metadata. So in this case users have to resort back to known minimum versions of the DBaaS Operator itself (or it's APIs) to get the dependency constraint. However the ability of DBaaS to provide MySQL 5.7 might go away in the future and there is no way to catch that with dependency resolution today. MySQL is known as the Operand here.

Prioritized deliverables:

• Operators can expose the Operand (workload / capability / service) that they offer and associated versions (similar to Debian virtual-package), i.e. a list
• Operators can express dependencies on those Operands
• Operand dependencies can be mixed with Operator version dependencies
• OLM resolver understands Operand dependencies among the other dependency types and can resolve the required Operators
• OLM resolver needs to understand compound contraints
• UI related: the metadata needs to support a human-readable representation of the Operand (and it's versions) to drive the Console

Open Questions:

• Should OLM have a facility that allows to set preferences for certain Operators should there be multiple candidates that provide the same Operand (or even the same Operand version)?
• Should OLM be capable of tracking operand versions on the cluster so that it can warn the admin when an upgrade of an operator would remove support of an operand version that's currently used on the cluster?

Related work:

• IBM ODLM Operator: Operand Deployment Lifecycle Manager
• Early design in hackmd: Operand Versioning / Image Selection Design Proposal