Make "odo link" compatible with the breaking changes introduced by Service Binding Operator

[dharmit]

Which functionality do you think we should add?

The Service Binding Operator project introduced breaking changes in redhat-developer/service-binding-operator#608 which will cause the "odo link" between a component and an Operator backed service to fail. odo is not compatible with the breaking changes introduced in the Operator.

Why is this needed?

It is needed to make sure users can upgrade to a version of odo that is compatible with this breaking change.

Acceptance Criteria

• Check if the cluster supports resources of type "ServiceBinding" using the GVK/R info.
• Create "ServiceBinding" instead of "ServiceBindingRequest" if it supports.
• Maintain backward compatibility for alpha version of SBO by keeping support for "ServiceBindingRequest".
• Integration Tests

/area service-operators
/area component
/kind feature

[dharmit]

@kadel @girishramnani @mik-dass @adisky

Maintain backward compatibility for alpha version of SBO by keeping support for "ServiceBindingRequest".

While working on this, I decided against doing this because maintaining backward compatibility, IMO, should be upon the tooling. For example, while adding support for devfile, odo took necessary steps to still support users working with s2i. Plus, as far as SBO is concerned, we're working with alpha and beta versions (correct me if I'm wrong.)

So it didn't feel essential to make backward compatibility for a different tooling in odo.

[wtrocki]

@dharmit SBO is still not GA (means in 0.x) so they can introduce breaking changes and tooling should simply update for it. Supporting both options in CLI is very very simple so not sure why this is actually closed.

SBO had a couple of major bugs fixed recently and I was wondering if you consider updating odo to support it (with breaking or nonbreaking changes)

FYI @gorkem @serenamarie125

[dharmit]

SBO is still not GA (means in 0.x) so they can introduce breaking changes and tooling should simply update for it.

We understand that, and hence we updated odo to use the latest version of SBO then. SBO has recently (in past couple of days) come up with a newer version (0..5.0 IIRC), and we will update odo to use that.

so not sure why this is actually closed.

It was closed because we updated odo to use newer APIs as you might see it here #3973 (comment).

SBO had couple of major bugs fixed recently and I was wondering if you consider updating odo to support it (with breaking or nonbreaking changes)

I think I answered that already, but we don't see an option of not updating odo to use the newer version of SBO.

[wtrocki]

and we will update odo to use that.

Ok. Thank you so much for clarification. That was my intention.
Looking forward for that change