As a Korifi API user I do not want to see a "type" field in my user provided serivce details in VCAP_SERVICES

[georgethebeatle]

Background

Right now when we bind a user provided service created with the following command

cf create-user-provided-service upsi1 -p '{"x": {"y": "z"}}'

to an app we get a VCAP_SERVICES env var value like this:

{
  "user-provided": [
    {
      "label": "user-provided",
      "name": "upsi1",
      "tags": [],
      "instance_guid": "7247d130-d534-42e3-95ee-d913aa7ae54e",
      "instance_name": "upsi1",
      "binding_guid": "78113e78-f54c-4529-8b18-46a92198c9c4",
      "binding_name": null,
      "credentials": {
        "type": "user-provided",
        "x": {
          "y": "z"
        }
      },
      "syslog_drain_url": null,
      "volume_mounts": []
    }
  ]
}

There is a type key under the credentials field of the service instance. This is a deviation from the CF v3 API spec and can break strict json unmarshalling in spme apps.

Acceptance

GIVEN I have an app called dorifi runnnig on Korifi
WHEN I cf create-user-provided-service upsi -p '{"x": {"y": "z"}}'
AND I cf bind-service dorifi upsi
THEN I can see that the VCAP_SERVICES env var of dorifi looks something like this:

{
  "user-provided": [
    {
      "label": "user-provided",
      "name": "upsi1",
      "tags": [],
      "instance_guid": "7247d130-d534-42e3-95ee-d913aa7ae54e",
      "instance_name": "upsi1",
      "binding_guid": "78113e78-f54c-4529-8b18-46a92198c9c4",
      "binding_name": null,
      "credentials": {
        "x": {
          "y": "z"
        }
      },
      "syslog_drain_url": null,
      "volume_mounts": []
    }
  ]
}

AND cat /bindings/<biding-guid>/type is user-provided
AND the backing secret in the k8s cluster is of type servicebinding.io/user-provided

---

GIVEN I have an app called dorifi runnnig on Korifi
WHEN I cf create-user-provided-service upsi -p '{"x": "y", "type": "my-type"}'
AND I cf bind-service dorifi upsi
THEN I can see that the VCAP_SERVICES env var of dorifi looks something like this:

{
  "user-provided": [
    {
      "label": "user-provided",
      "name": "upsi1",
      "tags": [],
      "instance_guid": "7247d130-d534-42e3-95ee-d913aa7ae54e",
      "instance_name": "upsi1",
      "binding_guid": "78113e78-f54c-4529-8b18-46a92198c9c4",
      "binding_name": null,
      "credentials": {
        "x": "y",
        "type": "my-type"
      },
      "syslog_drain_url": null,
      "volume_mounts": []
    }
  ]
}

AND cat /bindings/<biding-guid>/type is my-type
AND the backing secret in the k8s cluster is of type servicebinding.io/my-type

Dev Notes

Keep in mind that the secret type in Kubernetes is immutable and we have to somehow handle this when we update the service instance type. We could:

• Recreate the secret when there is a type change (react on the invalid update err)
• Leave the behaviour unspecified and return a generic error (we believe that this is a corner case, so we can wait until someone complains)