CUSTOMER PROBLEM

• We are in a bad shape w.r.t. how and where default values are applied
• https://issues.redhat.com/browse/ROX-8046
• https://issues.redhat.com/browse/ROX-22588

• Closely related to that, we are in equally bad shape w.r.t. evolving the schema as the operands (e.g. collector) changes - according to k8s API conventions, we make incompatible schema changes and we’re still on v1alpha1. So we are effectively not versioning our API. (Note that many OpenShift APIs are in the same (alpha) boat.)
• We do not have good guide-rails for evolving the API. For the more dynamically changing parts of configuration this results in getting ourselves painted into a corner, and consequently abominations such as forceCollection field.

Related (unfinished) discussion on slack.

ACCEPTANCE CRITERIA

1. A set of agreed-on guidelines on:
   1. how to introduce new fields into the operator API and subsequently evolve them. These guidelines must describe how we should have handled the above-mentioned issues if we were wiser from the start.
   2. how and in what situations to bump the operator API version.
2. Solutions to the child tickets.