Add a section about service bindings

[loewenstein]

No description provided.

[loewenstein]

Let's wait with this change until we might have a better answer for e.g. packit buildpacks.

[loewenstein]

@modulo11 I added the packit pull request. WDYT, should we add it like this to the RFC?

[c0d1ngm0nk3y]

What is the value gain in putting this into the RFC? There is noting to do on cf side, right?

[loewenstein]

Hi @c0d1ngm0nk3y,

it was specifically requested to be added in cloudfoundry#796 (comment), the other RFC had a section about it as well and an alternative to adding it to Paketo buildpacks is cloudfoundry#804 which would be work in CF for the benefit of being independent from a concrete implementation of CNBs.

Does it make more sense?

[c0d1ngm0nk3y]

I am just wondering if libpak and libcnb is too much details. But if the previous rfc already addressed this, this is already aligned. Isn't it? :)

[loewenstein]

The existing RFC ends with

Recommendation

Updating the Paketo buildpacks to consume Cloud Foundry environment variables appears to be the easier option. However, given that there are at least two viable options for buildpack service binding consumption, this RFC proposes making the final decision at implementation time.

[c0d1ngm0nk3y]

this RFC proposes making the final decision at implementation time.

I like that actually.

[loewenstein]

this RFC proposes making the final decision at implementation time.

I like that actually.

Isn't that very similar to what I propose here? I.e.

When cloudfoundry#804 gets approved and implemented (with option 2), this requirement will be removed.

Anyway, I am open for re-phrasing proposals, but I think we should include something about service bindings.

[c0d1ngm0nk3y]

this requirement will be removed.

I am just a bit confused. This is a requirement towards buildpacks and not cf, right? So I wonder what the benefit in mentioning this is. Especially since the predecessor pr already saw this as implementation detail.

But sgtm, I am just a little concerned that we put little by little to much into this RFC.