Parse type field from VCAP_SERVICES credentials

[tomkennedy513]

• currently the VCAP_SERVICES parsing will use the label from the binding as the type. This is problematic because user-provided bindings will always have label 'user-proved' which prevents users from creating custom bindings that are of a known type

[dmikusa]

My opinion is that this is working as designed. The type is 'user-provided' so that's what we should put into the service binding type.

I don't personally want to go down the path of adding custom rules that dip into the credentials and do things with fields that may or may not exist there. It's just more than I believe was intended with this feature in libcnb.

I read back over the stories where we added support for mapping VCAP_SERVICES to service bindings, and my understanding is that the intent was to provide a simple bridge that worked for most cases, not something that supports all possible use cases with VCAP_SERVICES. The intention was never to add first class support for VCAP_SERVICES. We discussed things like looking at or flattening credentials and that was deemed out of scope.

Can you expand on this use case, specifically why users can't move to service bindings?

@loewenstein-sap what do you think about this? Is this something you've seen from users? Also, I was under the impression that CF was going to support service bindings, so my preference would be to just have people use that. Not try to add more support for VCAP_SERVICES.

[loewenstein-sap]

cc @pbusko

[tomkennedy513]

An example of something that doesnt work is creating a user-provided binding for overriding settings.xml or doing ca-certificates. I originally had a pr to move this to the cnbapplifecycle for cf since it was more platform specific, but @pbusko and @loewenstein-sap prefer the parsing to stay in the buildpack libraries.

[tomkennedy513]

@loewenstein-sap If we are not able to add the type logic here, then I think we need to revisit cloudfoundry/cnbapplifecycle#98

[dmikusa]

OK, let's wait on some more opinions/thoughts then. I only focus on this one particular area/project, so I'd be curious to see if there's a plan for how this all fits together in the larger context of CF & what's going on there to support CNBs.

[pbusko]

OK, let's wait on some more opinions/thoughts then. I only focus on this one particular area/project, so I'd be curious to see if there's a plan for how this all fits together in the larger context of CF & what's going on there to support CNBs.

I believe this PR is rather a bugfix and is already implemented in packit with paketo-buildpacks/packit#657

[tomkennedy513]

@dmikusa I opened a similar pr in libpak to handle this behavior paketo-buildpacks/libpak#428. The issue is that now there is three different places handling VCAP_SERVICE bindings where there should only be one (cnbapplifecycle). Additionally, it feels odd to mutate the bindings after they are parsed since I can't limit the scope of the behavior to VCAP_SERVICES parsing. @pbusko I strongly believe we should revisit moving this behavior into the lifecycle because bindings don't fully work in the cnbapplifecycle unless you use a specific buildpack library that not every buildpack uses.