Overview:

A high level summary that describes this Task in a clear, concise way. Complete during New status.

In the release preceding one which removes a feature (that would cause errors for users who opted explicitly into such a deprecated feature) we could improve visibility of such impending breakage. This could be done by (in the order of increasing effort and visibility):

• An appropriate message in the CR status.
• Kubernetes events. These would be surfaced by kubectl describe and such.
• Plumbing such a message from the operator through to central and report it as a platform configuration issue. (Credit for this idea goes to Evan Benshetler.)

The same mechanism should be used to warn about explicitly specified (or previously defaulted) values for legacy fields which had been replaced in an API refactoring.

Acceptance Criteria:

A list of specific needs or objectives that this task must deliver in order to be considered complete. Complete during Refinement status.

• this will also need a note in dev docs to add such warning in advance