Closed georgethebeatle closed 1 year ago
FWIW, here's some OSBAPI client code for binding responses. Credentials should be a map of string to interface.
I left a comment on Slack about this as well: https://cloudfoundry.slack.com/archives/C0297673ASK/p1680190415283189
Basically Cloud Controller in CF for VMs is storing credentials as serialized JSON in a TEXT column in the database, so any valid JSON object type should be supported. One thing I think we could do is actually store the original input off on the UPSI Secret under a key like KORIFI_SERIALIZED_CREDENTIALS
or CF_SERIALIZED_CREDENTIALS
(or something) and use that when constructing VCAP_SERVICES
. We should still break out the credentials into individual keys/values on the Secret for K8s Service Binding support, but having what was originally provided through cf cups SERVICE_NAMED -p '{"some-cred": "some-value", "other-cred": 9000"}'
feels like what we need to do here.
It would be better to defer the modeling of the service binding credentials to when we start writing the managed service proposal
Blockers/Dependencies
Blocked by managed service support!
Background
As of today korifi is assuming that service credentials are key-value string mappings. However according to the v3 api spec the credential can be a more complex json object.
Here is an example of a service binding secret using more complex credentials:
Korifi should not assume a flat map as the structure of the service binding credentials
Action to take
Think of a better way of modeling thet service binding credentials. A map[string]any sounds like a better option.