Service-catalog: VCAP_SERVICES interop

[duglin]

Today we will take all of the creds from a binding and create one secret with each name/value pair from the creds as a new name/value pain the secret. This works well for us. However, this might not work well for users who are trying to port their CF app over to Kube as it would require them to change their code to no longer parse the VCAP_SERVICES environment variable to get the same info as what's in our secret name/value pairs.

In order to help with interop I'd like to propose that in addition to the name/value pairs in the secret we create today we also place the entire (raw) credentials object from the binding into the secret as a string with a name of VCAP_SERVICES or credentials.

I'm leaning more towards VCAP_SERVICES for two reasons, 1) it makes it clear we're doing it just for interop with CF, and 2) less of a chance of overlap with some other name/value pair in the secret.

Users who want to have app/code-level interop between CF and Kube can now just map this one name/value pair from the secret to the VCAP_SERVICES env var to get the desired results.

While this will increase the size of the secret (basically ~double the number of bytes), I don't think its that much overhead. Plus, having the raw data that came back from the broker might be useful one day - no idea what that might be, but ya never know.

thoughts?

If we're ok with this I'd like to get this in quickly so that we can demo this type of interop at any upcoming conference that we're showcasing this stuff. At the last CF summit (2 weeks ago) the question of interop between CF and Kube did come up (at this level as well as sharing of services/instances) so I think helping people out in this space will be good.

[pmorie]

Does this supercede the last issue you created for this? #881

[pmorie]

@duglin

I do not think that what you have described here yields parity with CF. What you have described, if I'm reading this correctly, is that we should have a flag on binding that results in the controller creating a single key for the binding payload from the broker called VCAP_SERVICES. That would mean that if I have two bindings, I would get two secrets that both have a VCAP_SERVICES key, which doesn't seem like what is desired.

I suggested in #881 that there could be an admission controller for the core that handles composing the secrets associated with all bindings in a namespace into a VCAP_SERVICES environment variable and mutates pods as they are created. That seems closer to what you want, does it not?

I have no objection to the creation of such an admission controller, and remote admission controllers (ie, not compiled into kubernetes) are at an alpha level in Kube 1.7, so the necessary building blocks should be there.

[pmorie]

We need to close this or #881 - your choice, @duglin

[MHBauer]

I STILL NEED TO KNOW WHAT VCAP MEANS!

[pmorie]

vmware cloud application platform

[duglin]

ug, yea, the multiple bindings issue is something I forgot about. The problem I see with an A.C. is that its global right? Will people be able to get VCAP_SERVICES on just some of their apps but not others? I'll close this issue and continue the chat over in #881