FEATURE: Align Binding secret with format of secret from [ibmcloud ks cluster service bind] command

[timroster]

Scenario

When using ibmcloud ks cluster service bind the entire credentials object from the key for a resource is stored as a kubernetes secret with the key binding

However when using the operator, for postgresql (for example) the credential object is parsed and top level objects are added as keys in the kubernetes binding secret. This results in key of connection and instance_administration_api in the secret.

Desired behavior / rationale

Using the same credentials content and binding to the same key name in the kubernetes secret would allow transition from using the CLI to create service bindings to the operator without changes to existing application code or deployment resource files.

Suggested Approach

Implement an option in the Binding CRD to specify ibmcloud kubernetes-service binding syntax compatibility

[vazirim]

@timroster We used to have a single key that contained the entire credential -- we will put this back.

This is also related to issue #123. The proposal there will make it easier to consume the postgresql credentials.

[cdlliuy]

@vazirim , just noticed this feature request . What is your plan on this?
I hope to remain the current behavior and put the binding as another entry inside the secrets. Currently, the coligo service binding and its further design is totally based on ICO's current behavior. I hope we won't switch to a single key completely.

[vazirim]

@cdlliuy The plan is to support both, so the current behavior won't change.

[JohnStarich]

@timroster We recently changed ibmcloud ks cluster service bind to support multiple fields. It should be safe to switch to the new fields from the ks ... bind scenario first, then switch to cloud-operators.

[timroster]

confirmed... but then again I was testing with a cloud-object-storage resource which is a global resource type which ks ... bind got correctly, but ICO struggled as the region in it's secret looked to default