Tags in User-Provided Service Instances

[Ben Hale]

James and Mark,

I was wondering what the current priority is for allowing users to add tags to user-provided service instances.  I've come across a use-case where they play a pretty important role.  At the moment, the New Relic support in the Java Buildpack looks at the content of VCAP_SERVICES for any service that has an "outer-most" key with newrelic in it:

{
  "newrelic-n/a": [ {
    "credentials": {
      "licenseKey": "12345678"
    },
    "label": "newrelic-n/a",
    "name": "new-relic",
    "plan": "standard",
    "tags": []
  } ]
}

This works just fine, but we've been asked to support "Bring-Your-Own" New Relic services using user-provided services.  In this case, the payload looks quite different:

{
  "user-provided": [ {
    "credentials": {
      "licenseKey": "12345678"
    },
    "label": "user-provided",
    "name": "application-mointoring",
    "tags": []
  } ]
}

As you can see, there's no way for us to determine that the user's service is a New Relic instance and do the zero-touch configuration.  We could potentially require the use of a naming scheme that requires newrelic somewhere in it, but that seems very onerous.  Instead, it'd be great if the user could tag an user-provide service instance with newrelic (and ideally add that tag to the in-built service for consistency) so that we could find it without requiring users to change their naming scheme.  Is the ability to add these tags to support this kind of use-case somewhere soon in terms of priority?

-Ben Hale

Cloud Foundry Java Experience

[Dr Nic Williams]

Interestingly I was wondering about tags yesterday too - my use case was to find the "smtp" service in the collection of bound services. If its via sendgrid/pivotal.io then you find it via tags. For user-provided, you only have the name. And this doesn't scale beyond a single service called "smtp".

Nic

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

Dr Nic Williams

Stark & Wayne LLC - consultancy for Cloud Foundry users

http://drnicwilliams.com

http://starkandwayne.com

cell +1 (415) 860-2185

twitter @drnic

[Matt Stine]

OK...I'll bite.

This is a more general issue for any "bring your own" service. I was working on a demo where I brought my own RabbitMQ to the table. spring-cloud depends on tags to automatically pick up services based on tags that we've defined in run.pivotal.io. Since I can't tag user-provided services, I can't get the same experience from a spring-cloud perspective, and I have to add additional code to make this work.

Would love to see this bumped up in priority. :-)

Matt Stine | Community Engineer, Cloud Foundry | Pivotal

901-493-5546 | Skype: mstine1978 | mst...@goPivotal.com

goPivotal.com

[Dr Nic Williams]

From a UX perspective, in the Ruby CLI, its to also prompt for list of tags. Or add an extra "--tags" flag to the go-cf CLI.

And support POSTing a set of tags to the API endpoint.

PRs welcome :D

[James Bayer]

shannon (pm for services) is now aware of this thread and should be replying soon. 

Thank you,

James Bayer

[Shannon Coen]

Hello,

Thank you all for your input; I've had this story in our icebox for a few months. I'll put some more thought into it, and consider whether we can get to it in the near future.

When we get to it, the feature would be added to the go-cli, not the ruby-cli.

Best,

Shannon

[Ben Hale]

When we get to it, the feature would be added to the go-cli, not the ruby-cli.

 I understand that you guys don't commit to dates readily, but what is the general timeframe for the go-cli being production ready?  Is it like a couple of weeks or a couple of months away?  I'm just concerned that this feature might be "held hostage" by another project's priorities.

[Scott Truitt]

Hi Ben,

We're planning a public beta release soon, most likely next week. Feedback from the community and final feature work will dictate the timing of the final release, so we'll all know more after the beta. 

Scott

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Ben Hale]

We're planning a public beta release soon, most likely next week. Feedback from the community and final feature work will dictate the timing of the final release, so we'll all know more after the beta. 

Great news.  Thanks for the update.

[Mike Youngstrom]

It seems to me that this would be a better case for custom service input during service creation.

* During "create-service" a user when choosing "new-relic" should then be prompted for a plan.

* The plan may be "Existing license".

* Then prompt for the license key.

* This data should then be sent to the service broker to be validated and added as credentials.

A more difficult thing to implement but seems to me the right solution for this problem.

What is the idea behind tags?

Seems to me Ben could accomplish the same kind of hack by renaming your "licenseKey" property to newRelicLicenseKey.

The real solution is custom service specific user input.  We have 10s of use cases in our org for custom service user input that a "tags" hack wouldn't solve.  I would prefer time and effort be spent with a better end solution that solves the problem in a more complete and end user friendly manner.

Mike

[Shannon Coen]

I really like Mike's suggestion of keying off of a New Relic specific key in credentials. This is something users already have the ability to input and would work for both managed and user-provided instances. Ben, will that work for you? It seems like this would solve Matt Stine's use case as well, if spring-cloud could identify a rabbit service by 'uri: amqp://...', for example. For Nic's use case, wouldn't the credential 'smtp_host' provide sufficient info? 

If necessary, I can work with service partners on run.pivotal.io to provide more useful credential keys. We have somewhat of a standard described here: http://docs.cloudfoundry.com/docs/dotcom/marketplace/provider/#binding-credentials, but this can evolve. 

Tags are intended to provide a category/class/kind/type (monitoring, search, mail, datastore). They are an attribute of the service, not the service instance and I plan for these to be used by cloud controller clients for categorizing/filtering catalogs of services. With this in mind, adding the specific name of a service would pollute the list of tags. 

Mike, your feedback with regard to support for user input of arbitrary provisioning data is valuable. You're not the only one who wants it, and the v2 broker draft spec is driving an internal conversation about it. 

Shannon

[Ben Hale]

I really like Mike's suggestion of keying off of a New Relic specific key in credentials. This is something users already have the ability to input and would work for both managed and user-provided instances. Ben, will that work for you? It seems like this would solve Matt Stine's use case as well, if spring-cloud could identify a rabbit service by 'uri: amqp://...', for example. For Nic's use case, wouldn't the credential 'smtp_host' provide sufficient info? 

I dislike this because what it's actually doing is moving the tagging into the payload field.  It pollutes a clean naming (e.g. I assume that licenseKey is in the NR team's ubiquitous language, newRelicLicenseKey is not) that each service would ideally like to use.  What we're effectively saying to service providers is that their payload keys now need to be unique within the context of all possible service payloads rather than simply unique with their payload.

The other problem I see here is that it's not extensible.  We already see in the db-as-as-service tags that it's useful to put multiple tags on a single service (e.g. database, relational, postgresql, 9.2,  mysql, etc.) so that consumers that care about varying levels of granularity can all find what they are looking for based on a reasonable tag.  By simply pushing tags into the payload keys, you cannot say that NR is both a monitoring-service, newrelic, and 3.0, all at the same time.

Exposing tags more widely requires no backwards-incompatible changes and allows service providers to use key names that match their internal ubiquitous languages.  The beauty of tags in other contexts is that they're very free-form allowing emergent behaviors around them.  Why exactly are we against allowing any and all tags to exist on services?  It seems like it can't hurt (they can just be ignored) and potentially allow behavior we haven't yet thought of.

[David Williams]

 It seems like it can't hurt (they can just be ignored) and potentially allow behavior we haven't yet thought of.

 

Ben makes a great point here, and it's something that we're faced with when discussing internal/private CF deployments with customers that want to integrate with their own external services.  I think the discussion around run.pivotal.io is different that Mike Y's case, for example.  With run.pivotal.io, you have more control with what a service provider offers to users and how they offer their services, guaranteeing consistency...you can control and anticipate the supported use cases.  However, with private CF deployments there are more user cases than can be anticipated, and so you need a greater amount of flexibility with fewer constraints.  For me, the concept of tags to customize metadata to help CF operators to define and CF users identify various nuances of a user-defined service (version, service levels, location, product, architecture, environment, or capability to name a few) for a given user-provided service seems like a worthy cause.

[Mike Youngstrom]

I dislike this because what it's actually doing is moving the tagging into the payload field.  It pollutes a clean naming (e.g. I assume that licenseKey is in the NR team's ubiquitous language, newRelicLicenseKey is not) that each service would ideally like to use.  What we're effectively saying to service providers is that their payload keys now need to be unique within the context of all possible service payloads rather than simply unique with their payload.

I'm not in any way saying that using "newRelicLicenseKey" be the end all solution.  I'm saying that it is a hack that can be done for now.  IMO an only slightly worse hack than using a tag on a user provided service.  Do you disagree Ben that prompting for a key as part of the creation of an actual new-relic service is the better way of handling this use case long term?  I don't really care what hack you use but it would be unfortunate if implementing the tags hack distracted from the real solution of being able to provide service specific data to services at creation time.

Mike

[Ramnivas Laddad]

While Ben and Matt covered pretty much what I want to say, let me add some color from spring-cloud [1] point of view (but really any library such as vcap-ruby [2] and vcap-node [3] should those start to be developed actively again).

While spring-cloud is pretty flexible in how it can inspect the services payload (hey, it even works on Heroku [4], even though for now just the postgres service), it works particularly well when service payload have some uniformity. For example, its base classes rely on tags as the primary mechanism and labels as the secondary for matching payload to the kind of service. User services that expose either tags or labels in a sensible manner will have a much easier time implementing extension (in many cases, requiring no extension at all). If neither are available, extensions are forced to parse the whole payload to check if it meets some criteria (url, for example). For newrelic in user-provided service form, looking for licenseKey seems brittle as best (will break the first time some other service exposes the same attribute). Yes, something like newRelicLicenseKey will be less brittle, but at that point why exposing tag not a better solution? Instead of asking service providers to ensure that they expose unique payload (considering all existing and **future** services), it seems easier to ask them to "add whatever tags that make sense for your service".

-Ramnivas

[1] https://github.com/spring-projects/spring-cloud

[2] https://github.com/cloudfoundry-community/vcap-ruby

[3] https://github.com/cloudfoundry/vcap-node

[4] https://github.com/spring-projects/spring-cloud/tree/master/heroku-connector

[Mike Youngstrom]

Thanks Ramnivas, this helps me to understand this use case for tags a little better.  I was thinking that in a perfect world libraries would use the service type to determine the service type rather than tags and labels.  I suppose it is a viable use case that you could have multiple service brokers (types) that all produce credentials compatible with a mysql client, perhaps differing on version of mysql, mariadb vs mysql, etc.  In such a case you'd like to be able to have client libraries, buildpacks, etc. parse these credentials in a consistent way.

Though I still think that custom service arguments would be the proper way to address the New Relic use case, instead of a user provided service, I can see the value in tags providing an abstraction tools can use to operate on credentials without the tool having to rely on the actual service type.

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Ben Hale]

I'm not in any way saying that using "newRelicLicenseKey" be the end all solution.  I'm saying that it is a hack that can be done for now.  IMO an only slightly worse hack than using a tag on a user provided service.  Do you disagree Ben that prompting for a key as part of the creation of an actual new-relic service is the better way of handling this use case long term?  I don't really care what hack you use but it would be unfortunate if implementing the tags hack distracted from the real solution of being able to provide service specific data to services at creation time.

 Well, that only works for services that are both user-provided and platform-provided.  In fact, New Relic is only an example on http://run.pivotal.io as it won't be available by default to on-premise users.  In fact, I don't believe that there are any services included by default at all any more.  If we went with the 'provide your own credentials when creating a service' model, then we'd also have to support the user-provided style as well for cases where there is no service binding for the type the user wants to bind (another example would be an Oracle database).  If we've got to support the user-provided style no matter what, why don't we go for a single unified solution (tags) that works for all cases?

[Mike Youngstrom]

 Well, that only works for services that are both user-provided and platform-provided.  In fact, New Relic is only an example on http://run.pivotal.io as it won't be available by default to on-premise users.  In fact, I don't believe that there are any services included by default at all any more.  If we went with the 'provide your own credentials when creating a service' model, then we'd also have to support the user-provided style as well for cases where there is no service binding for the type the user wants to bind (another example would be an Oracle database).  If we've got to support the user-provided style no matter what, why don't we go for a single unified solution (tags) that works for all cases?

In the near future it is going to get much easier to create custom services and deploy them to cloud foundry.  I would prefer to push deployers towards a future of creating their own services that are much more friendly to their users than user-provided.  But I get your point.  Especially between 2 different custom services I see the value in a unified tag solution, or something like this, for tooling even between custom services.

Mike

 

[Guillaume Berche]

Shannon/Scott,

Do you have updates on plans to add the ability in the go cli to specify tags in services instances (seems to match stories [1] and [2]) ?

The java-buildpack support for selecting services to use based on the tag (as an alternative to service name* ) seems quite useful to me, and much more flexible than imposing specific service names or specific config in the buildpack.

Thanks in advance,

Guillaume.

* label only being a synonym for name according to [4]
[1] https://www.pivotaltracker.com/story/show/72117050
[2] https://www.pivotaltracker.com/story/show/61861194
[3] https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md#redis
[4] http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#VCAP-SERVICES

[David Lee]

HI Guillaume,

I'm working on CLI now so I'll try to answer.

Generally speaking yes, if the CC or services API is adding a new command the CLI will generally add a corresponding command. It might take some time and there are some exceptions. However, for something like this it seems it would make sense to expose this to the app user.

Did someone indicate differently before? Maybe I am missing some context?

Thanks,

-Dave

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/37894e30-4e4a-4df7-a8b0-d11d35334e65%40cloudfoundry.org.

[Cornelia Davis]

I've chatted with Shannon about this and the issue initially was that tags are set (and stored) at the service "type", not at the service instance level; since UPS is really like a service "type", there was no way to have tags at the instance level. But now with this new story about adding tags at the service instance level tags, we should be able to have them at the user provided service instance. The story that you pointed to, Guillaume, [1] does not, however include doing this for "gcf cups". David, is there a story to add instance specific tags to UPSIs?

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAM766KnWJGsGjBb3xU7gVZGnCEY6R7VgcUv-TK51uibFP8ZkFg%40mail.gmail.com.

[Guillaume Berche]

Sorry David, I missed some recent updates in the stories that is providing details, sorry for the noise (I did not mean to be pushy).

BTW, here is another use-case where ability to set tags on service instances (both managed and UPS* ) would provide value: some JavaEE apps expect RDMS services to be bound to DataSource objects keyed by jndi key name (see more context in JavaEE specs [1] section EE.5.18.3DataSource Resource Definition) so that they can be looked up by this key such as:

public class MySessionBean {
@Resource(lookup = "java:app/MyDataSource")
DataSource myDB;
...
}

A tag such as "jndi-key" associated with a service instance of type RDMS would allow the buildpack to prepare bind a DataSource element with this key in the jndi keyspace. This will increase binary compatibility of some multi DataSource JavaEE apps on CF without requiring them to be modified use spring-cloud or cloudfoundry-client-lib

Guillaume.

* thanks Cornelia for pointing the cups specificities w.r.t. current story
[1] http://download.oracle.com/otndocs/jcp/java_ee-7-fr-eval-spec/index.html

[David Lee]

Guillaume,

No worries. I'm just getting up to speed here myself.

Cornelia,

I'm not aware of that being added to the CC API. Do you know if that's already happened?

-Dave

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/5f54c51c-dba4-4314-b7ef-05763a5e5142%40cloudfoundry.org.

[Cornelia Davis]

I don't know, but the original story Guillaume referenced [1] I assume will be adding CC api to add tags for create-service. The point I am making is that we need a similar story for UPSI - don't want to see those diverge - the fact that managed and external services are (mostly) treated the same in the elastic runtime is a hugely POWERFUL feature.

[1] https://www.pivotaltracker.com/n/projects/969486/stories/61861194

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAM766KmvQMpS5UozbZ-D3YWX7CpVf9oP-ewN6P4a-20j%3D9LKgQ%40mail.gmail.com.

[Guillaume Berche]

Actually, the use of tag for annotating bound service instances would require more than currently documented into VCAP_SERVICES: it needs a key/value pair tag similar at what AWS offers to set on resources and not just an array of tag names [2] .

Also the key/value tag pairs attached should be attacheable on the service instance and/or service bindings. Service binding by default getting tags assigned to service instance, unless overriden in the bind-service request.

The service-binding level tag would allow the following popular use-case in our jee apps: push a standard SQL-UIs for accessing RDMS instances bound to other apps (e.g. as a workaround to the lack of the "cf tunnel" / cadelcott ability in CF v2)

In more details:
- an app1 (pushed from app1.ear) is bound to a RDMS services S1 and S2 and expects JNDI key k1 and k2 (e.g. k1="model-db" and k2="stats-db") to lookup each associated DataSource
- a second app2 (e.g. MysqlAdminUi, pushed from app2.ear) is bound to the same service S1 but expects a different key (e.g. "db"). The key is different mainly because app2.ear is a reusable off-the-shelf component shared by many apps

Any chances to consider these two changes as part of the two stories [3] [4] ?
- service binding tags
- key/value tags instead of just tag names

Thanks,

Guillaume.

[1] http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#VCAP-SERVICES
[2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html
[3] https://www.pivotaltracker.com/story/show/72117050
[4] https://www.pivotaltracker.com/story/show/61861194

[Ben Hale]

Actually, the use of tag for annotating bound service instances would require more than currently documented into VCAP_SERVICES: it needs a key/value pair tag similar at what AWS offers to set on resources and not just an array of tag names [2] .

This would be ideal, but for backwards compatibility it might be reasonable to keep single element tags and use a structural convention, e.g.

[
  'relational',
  'postgres',
  'session-replication',
  'jndi=java:app/MyDataSource',
  'jdbc=http://central.maven.org/...',
  'connections=25'
]

You might also argue that some of that information (specifically the key-value pairs) should actually be credential information.  Custom credential payloads for non-UPS services might also be an avenue worth exploring.

Also the key/value tag pairs attached should be attacheable on the service instance and/or service bindings. Service binding by default getting tags assigned to service instance, unless overriden in the bind-service request.

I see three levels of tags (and/or credential information) with ascending priority

1. Service Broker.  All service instances provisioned by the broker get some information (e.g. postgres, relational)
   
2. Service Instance.  A provisioned service instance gets some information (e.g. url, connections)
3. Service Binding.  A bound service instance gets some information (e.g. session-replication, jndi)

I can think of scenarios in the Java Buildpack/Java Experience that would take advantage of information scoped at all three levels.

[Shannon Coen]

Rather than adding support for tags to the current create-user-provided-service command, I'm targeting deprecation of the user-provided commands in favor of support for user-provided instances using the standard 'create-service' command and arbitrary provision params [1]. This idea was suggested by the Mikes at LDS some time ago and I've been keeping the flame alive in my roadmap. By adding support for tags to only the create-service [2] and upcoming update-service commands [3], we'll get support for tags with user-provided service instances as well.

The CLI command to create a user-provide service instance with credentials and list of tags will look something like:

cf create-service user-provided default myupsi -p '{"uri":"mysql://user:pw@host/db"}' -t 'list, of, tags'

In summary, support for user-provided tags with user-provided service instances is achieved once we:

- add support for user-provided tags on managed service instances [2]

- add support for arbitrary provision params [stories to be written]

- enable creation of user-provided instances using the 'create-service' command and arbitrary provision params [1]

[1] https://www.pivotaltracker.com/story/show/67857170

[2] https://www.pivotaltracker.com/story/show/61861194

[3] https://www.pivotaltracker.com/story/show/72117050

A note about some use of language in this thread. Service brokers are distinct from service offerings. A broker can have many service offerings in its catalog. The use of 'type' in this thread is confusing and ambiguous; it appears to have been used to refer to the broker, the service offering name (CC API uses field called 'label'), and the underlying technology of a service (such as mysql, which can appear as a tag).

Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

mobile: 415.640.0272

skype: shannoncoen

--

You received this message because you are subscribed to a topic in the Google Groups "Cloud Foundry Developers" group.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b221e445-4ee6-4ee1-9065-2a32da16ec4c%40cloudfoundry.org.

[Mike Youngstrom]

Awesome news Shannon!  I look forward to those stories.  Can we get support for multi-level (full) JSON instead of just flat JSON too?

I like the CLI simplicity proposed too.  If a service creator wished for a more constrained service creation command then they can provide an optional CLI plugin.

Mike (Excited)

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAJKcadV_Ga0ZCeHVY8jVX_WPJtNPbkcDm0pFxNRQcq_zZS84WA%40mail.gmail.com.

[Shannon Coen]

Hi Mike,

With regard to arbitrary provision (and bind) params, I would expect multi-level JSON to be supported. 

Best,

Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

mobile: 415.640.0272

skype: shannoncoen

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAEoPEDpvCPQvUQQ5Cip68uzGgyxfVLQkHqPrgGfau5DUpyy_ww%40mail.gmail.com.

[Mike Youngstrom]

bind params????  Interesting.

Mike

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAJKcadW4vginjf2gXPL%3DjRt877oDKim%3D%2BG04YX%3DdsC2X16W7mg%40mail.gmail.com.

[Shannon Coen]

An example of an arbitrary bind param that might be meaningful for a particular service: 

cf bind-service myapp myserviceinstance -p '{"read-only":true}'

Which would request that the credentials generated for the bind should not have write privileges.

Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

mobile: 415.640.0272

skype: shannoncoen

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAEoPEDpd6Ge5%3DBhF-TfTxWXsEv6rk%3DuUMuyfAgvx_vSsCaNELg%40mail.gmail.com.

[Guillaume Berche]

Hi Shannon,

Thanks for the detailed update on this and pointers to the stories which sound great! The arbitrary params in the bind service meets well the need use-case of assigning jndi names to bound relational database services.

Guillaume.

[Aristoteles Neto]

When you say arbitrary bind parameters, do you mean the fields in [1]? Or subfields within ‘credentials’/something else?

[1] https://github.com/cloudfoundry/dea_ng/blob/master/lib/dea/env.rb#L18

Aristoteles Neto

ne...@orcon.net.nz

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAJKcadW4vginjf2gXPL%3DjRt877oDKim%3D%2BG04YX%3DdsC2X16W7mg%40mail.gmail.com.

[Shannon Coen]

Neither. These are configuration options which are meaningful to a service during the generation of binding credentials. The credentials generated would still be expected in the same format. This configuration data is not necessarily meaningful to an application; I don't imagine it needs to appear in the VCAP_SERVICES environment variable. 

The concept of bind params feature is in its infancy and is not a priority. We won't begin implementation without thinking it through further, exploring use cases, considering relative priority, and drafting/socializing a design proposal. If you think this mechanism would solve problems for you, let me know.

Thank you,

Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

mobile: 415.640.0272

skype: shannoncoen

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/C22B5052-723C-4956-9458-B3FF6EF421FC%40orcon.net.nz.

[Guillaume Berche]

Hi Shannon,

The use-case I was mentionning of assining a custom name in the jndi namespace to a service requires the arbitrary bind parameters to be available to the application (and its buidpack). I imagine most of use-cases Ben Hale mentionned [1] also require the same. I'm looking forward to a design proposal to further contribute use-cases that such feature would address.

Guillaume.

[1] https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/qOT2dwkcOnM/SXLN8tvBrWQJ