Upgrade to Service Binding operator to v0.5.0

[astefanutti]

v0.5.0 has just been released. #2076 prepares the ground by upgrading to an intermediate version, but v0.5.0 introduces breaking changes in the ServiceBinding API that should be integrated. See:

https://github.com/redhat-developer/service-binding-operator/releases/tag/v0.5.0

[astefanutti]

/cc @johnpoth

[johnpoth]

That was fast! I can take a look

[arthurdm]

I am interested in learning more about the connection and usage between Camel K and Service Binding, as I work on the Service Binding Spec. Any details that could be shared?

[astefanutti]

@arthurdm you can find some details in https://github.com/apache/camel-k/blob/master/proposals/service-binding/service-binding.adoc.

[johnpoth]

There is also a meeting where use cases can be discussed. Next one is today at 1:00 PM UTC I think

[johnpoth]

@arthurdm I think one part of the specification that is relevant here is the use of custom service projection where camel-k handles the mounting of the binding information (in the form of a secret) into the Deployment. I am mentioning this as it's scheduled to be removed if my understanding is correct.

One of the benefit of using this approach was that the Deployment did not have to be created in an incomplete state: waiting for the binding information and the resulting Pods failing.

Leveraging application-resource-mapping might let us achieve the same behavior.

[arthurdm]

Thanks for link @astefanutti / @johnpoth!

Yes - are you noted, we're about to remove the CustomServiceProjection from the spec. In order to leverage the new ClusterApplicationResourceMapping artifact my recommendation would be to expose the needed elements (volumeMount, env, etc) in the .spec of Integration - so that we don't get into a reconciler loop when the Service Binding Operator changes the generated Deployment that is owned by the Camel K Operator.

[astefanutti]

I've created #2096, as an umbrella issue to make Integration PodSpecable.

[johnpoth]

In the case of ServiceBinding, the integration isn't needed to be PodSpecable

[astefanutti]

In the case of ServiceBinding, the integration isn't needed to be PodSpecable

It seems that was the case an hour ago 😉.

[astefanutti]

Fixes with #2094.