1
votes

My problem can be reduced to this case: I want to have a service with single REST entrypoint returning some message. Because it is very useful to me I would like to have few instances of it but each returning different message that I specify. Of course each of those service instances would be bound to few apps. So I wonder how to accomplish something like that.

It looks to me that the best way to do this would be passing some parameters during create call on broker (http://docs.cloudfoundry.org/devguide/services/adding-a-service.html#create). But doing this is impossible. Do you know any way to create multiple instances of some service differing by some parameters passed during startup? I want to have full CF instance management (if it crashes it should be restarted etc.) and I would like to avoid creating them as apps with different parameters passed as environment variables ...

UPDATE: Amount of different messages (and instances) can be quite big and their content is unknown in advance. This somehow disqualifies using service broker plans (one plan per message).

2

2 Answers

2
votes

On the roadmap are features to enable users to specify config properties along with the {create,bind,update} service instance operation. From the platform's perspective, these properties are arbitrary and opaque, the platform will just pass them through with the request to the broker. The broker will be responsible for validation and returning meaningful user-facing error messages. The broker author will be responsible for communicating to users supported attributes out-of-band.

It sounds like you've got an app which implements the broker API endpoints and which also provides the message-endpoint-aaS. How will your app provide different messages on a single endpoint? Or will your app support an endpoint per service instance?

Eg.

For apps bound to service instance 001, your broker returns credentials "url": "app.route/instances/001"

GET /instances/001/ { "message": "message001" }

For apps bound to service instance 002, your broker returns credentials "url": "app.route/instances/002"

GET /instances/002/ { "message": "message002" }

Until we implement the feature I described above, I recommend broker authors enable users to configure the instance directly after provisioning.

Your app could support this with a PUT endpoint a user could curl directly, or with a simple GUI (see our docs on service dashboard SSO).

0
votes

Not sure if I properly understand what you're trying to do, but I think you might want to consider creating a number of Service Plans for the service you want to implement. Each plan would create service instances with different (predefined) parameters. You would need to create your own service broker for this.