Support Spring Data Apache Geode

[nebhale]

Add Spring Data Apache Geode support.

[nebhale]

No work needs to be done.

[jxblum]

@nebhale + @ekcasey - I'd be curious to learn more about what led to "No work needs to be done."

Specifically, what has or has not be technically done or what (e.g. SDG, or SBDG) is handling this concern for SC bindings?

@ekcasey and I spoke awhile back but curious what our discussion and her further findings led to after we talked.

Thanks,
@jxblum

[ekcasey]

Hey @jxblum!

SBDG currently uses the flattened version of VCAP_SERVICES and spring-cloud-bindings registers a kubernetesServiceBindingFlattened PropertySource that always provides the flattened bindings. Therefore the level of support is analogous to what is currently required by SBDG without requiring additional work. The one caveat is that the service bindings generated by PCC include nested data that can't be represented in the new binding format.

Happy to chat more

[jxblum]

Hi @ekcasey - Thank you for your response.

Just a quick followup... Is this "kubernetesServiceBindingFlattened" PropertySource named as such?

Currently, inside SBDG, when I construct a helper object (i.e. VcapPropertySource instance) from the Environment, I am expecting (this) there to be a specifically named PropertySource called "vcap".

The "vcap" PropertySource is then further validated to contain specific properties (specifically, using a pre-constructed/determined Predicate), which expects the "vcap.application.name" and "vcap.application.uris" properties to exist.

I gather that we are essentially letting Spring Boot's existing CloudFoundryVcapPostProcessor do its work then? Even inside a Kubernetes environment?

[ekcasey]

Just a quick followup... Is this "kubernetesServiceBindingFlattened" PropertySource named as such?

Yes!

Currently, inside SBDG, when I construct a helper object (i.e. VcapPropertySource instance) from the Environment, I am expecting (this) there to be a specifically named PropertySource called "vcap".

To integrate with Spring Cloud Bindings, SBDG will likely need to look for the new kubernetesServiceBindingFlattened property source.

I gather that we are essentially letting Spring Boot's existing CloudFoundryVcapPostProcessor do its work then? Even inside a Kubernetes environment?

This library works with credentials provided in the format specified in https://github.com/k8s-service-bindings/spec, or https://github.com/buildpacks/spec/blob/main/extensions/bindings.md (the latter will eventually be removed in favor of the former spec). In general, Spring Cloud Bindings are not CF-specific and therefore we make no assumptions about whether CloudFoundryVcapPostProcessor runs. TAS on k8s may or may not continue to set and use VCAP_SERVICES or VCAP_APPLICATION. I assume that, if service credentials are provided in VCAP_SERVICES, this would be a temporary solution for compatibility before migrating to the new specification, but I don't actually know what the plan is there.