Service Binding Extension

[nebhale]

This change adds the Service Binding extension specification as proposed in RFC #12.

[jkutner]

+1 assuming we change "Service bindings" to "Bindings" and services/ to bindings/

[nebhale]

@hone Final change made and ready for ratification.

[tinygrasshopper]

I am interested to know the reasoning behind restriction of associating the binding to only one kind of service "kind", rather than multiple.

In my mind today a binding credential can be matched to multiple abstract classifiers. The usecases that come to mind for multiple kinds are:

1. A service that supports multiple protocol connection options, like Apache Geode, which can be accessed by its API, or a memcached compatible client. I would expect this binding to have kinds: ["memcached", "geode"]

2. A service that supports multiple variations, and gives the client options to connect to it. RMQ is an example of this usecase, here is an example binding block today(link). In the example the connection string has multiple options for the client; I would expect this to have kinds: ["rmq", "rmq.amqp", "rmq.mqtt", "rmq.stomp"]

3. Multiple types of services that share a "kind", for example a mysql today looks like:

{
        "hostname": "q-n3s3y1.q-g614.bosh",
        "hostnames": [
          "q-m1280n3s0.q-g614.bosh",
          "q-m1279n3s0.q-g614.bosh"
        ],
        "jdbcUrl": "jdbc:mysql://q-n3s3y1.q-g614.bosh:3306/service_instance_db?user=8f26bbcb0f7645cf9924d715d5a0f130&password=3151t75a7xotcgwc&useSSL=false",
        "name": "service_instance_db",
        "password": "3151t75a7xotcgwc",
        "port": 3306,
        "uri": "mysql://8f26bbcb0f7645cf9924d715d5a0f130:3151t75a7xotcgwc@q-n3s3y1.q-g614.bosh:3306/service_instance_db?reconnect=true",
        "username": "8f26bbcb0f7645cf9924d715d5a0f130"
}

Its connection block has information for clients to use it as a "single node mysql", "multi node mysql" or a credentials blocks with a "jdbc" connection string. I would expect the kinds for this type of a binding response to be ["mysql", "mysql.single-node", "mysql.multi-node", "jdbc"]. Similarly a postgres binding response might have a postgres specific keys, as well as a jdbc connection string, in that case the kinds would be ["postgres", "jdbc"].

[hone]

@nebhale does this mean during launch you can't unbind a secret?

[nebhale]

Yes, that's the implication. Given the possibility of functionality that watches for changes to the contents of the files and then propagates those changes into the running application (e.g. watching for credential rotation), then the disappearance of files might cause a problem. For systems wanting to be "revoke" a credential, I think that's better handled on the server side (stop accepting new connections with the credential, terminate any sessions currently using the credential) because removing the credentials from the filesystem doesn't force a client to stop using the previously read content.

[nebhale]

@tinygrasshopper I think the tying of a binding to a single abstract kind is because I view bindings as lightweight projections of a given concrete thing. Therefore I don't view multiple bindings that are all slightly different projections of the same thing as being a problem. To address your examples:

1. I would be comfortable (if not expect) the creation of a Geode instance to result in two bindings being projected into an application. One that is Geode API-specific and one that is memcached-specific. The reasoning behind that is that the a memcached client doesn't really care who exposes a memcached-compliant endpoint and if it does, this would be exposed as a kind:memcached/provider:apache-geode pairing. Having two bindings projected in doesn't have any material cost, but also simplifies reasoning about a binding payload.
2. I think that different connection-protocols are still of a single kind. As in "this is a RabbitMQ server, here is an arbitrary credential payload that contains connection information for the different protocols that RabbitMQ supports"

my-rabbitmq
├── metadata
│   ├── connection-count
│   ├── kind
│   ├── provider
│   └── tags
└── secret
    ├── endpoint.amqp
    ├── endpoint.mqtt
    ├── endpoint.stomp
    ├── password
    └── username

3. I don't think that kind is the proper abstraction for indicating what can be found in a payload (there's some discussion of describing those schemas already in the world). I view kind as a very course grained "here's the thing that is being projected through".

Where I think I really agree with you is that there's not obvious description of how fine or course grained the kind should be for a binding. I don't know that there's a right answer beyond experimentation and so I tend towards less-complex projections and more of them, at least during this experimental point in time.