There is concern that OSP services get restarted when operators are updated. Now that we have an initialization resource we could provide more control over how the operator updates proceed. The initialization resource currently updates all operators at once, but we could implement a mechanism to sequence operator updates so that we minimize upgrade impacts ensuring that only 1 OSP service is reconciled at a time.
 
We already know for example that  https://github.com/rabbitmq/cluster-operator/releases/tag/v2.11.0 will cause the RabbitMQ cluster to immediately restart (we aren’t using 2.11 yet but soon will be). Furthermore may lib-common changes to our core labels/annotations or primitive k8s structures would likewise cause a similar restart concern for OSP services immediately upon operator updates. While these updates are normal and expected is is the fact that we are doing them all simultaneously that is a concern here.