Owner: Architect:

_<Architect is responsible for completing this section to define the
details of the story>_

Story (Required)

We should mark CoreOS bindings as deprecated in their CRD.

Background (Required)

With SBO 2.0, we're removing support CoreOS bindings. Before we can remove them, we should announce to our users that this is happening, preferably with a version release. One thing we can do is to mark them as deprecated within kubernetes, so that making new service bindings explicitly throws a warning.

Out of scope

• Don't remove CoreOS bindings entirely; that happens in 2.0. This story is targeting v1.4
• Convert CoreOS bindings to their corresponding spec binding; since it's not a 1:1 mapping, we will need to handle that separately.

In Scope

• Marking the CoreOS bindings as deprecated.
• Document the deprecation and the non-automated upgrade path to spec bindings

Approach(Required)

Apply the appropriate kube-builder deprecation notice on the CRD and regenerate manifests.

Demo requirements(Required)

Attempting to make a service binding should mark it as deprecated.

Dependencies

None

Edge Case

While we're marking them as deprecated, do we want to auto-convert them to spec bindings (when possible)? Or should that be left for a separate story?

Acceptance Criteria

CoreOS resources should be marked as deprecated within the CRD.
QE:
Documentation: Document the deprecation and the non-automated upgrade path to spec bindings
Upstream: Y
Downstream: Y
Release Notes Type: Deprecated Functionality

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

v

Legend

Unknown

Verified

Unsatisfied