Re: Proposal for named service bindings


Mike Youngstrom
 

The proposal still has my vote FWIW. :)

Mike

On Sat, Apr 1, 2017 at 7:11 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

The approach with tags has some issues too:
- User-provided services have no tags
- Ambiguous. Tags are not unique so it is possible that the same tag
appears in multiple service instances bound to the same app
- It is possible that different apps put different meaning in the same
tag. This can lead to problems if a service instance with this tag is bound
to these apps.

Generally service bindings act as input to applications, similar to
function arguments. Usually we want to name each input so it has a clear
purpose.

So, please consider again the proposal to add name on service bindings.


On Wed, Mar 15, 2017 at 9:06 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Ok, this might work.
Will try it.

Thanks for the update.

On Wed, Mar 15, 2017 at 12:54 AM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

I spot a CLI question?



But if you have created a service instance and later you want to bind
it to a new app, can you add the tag expected by that app to the existing
service instance?



`cf update-service mydb -t "list, of, tags"`

http://cli.cloudfoundry.org/en-US/cf/update-service.html



Regards,

Dies Koper
Cloud Foundry Product Manager - CLI





*From:* Peter Dotchev [mailto:dotchev(a)gmail.com]
*Sent:* Tuesday, March 14, 2017 6:17 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* [cf-dev] Re: Re: Re: Proposal for named service bindings



Yes, tags at service instance level could work.

But if you have created a service instance and later you want to bind it
to a new app, can you add the tag expected by that app to the existing
service instance?

Also tags do not identify a service instance uniquely, so it is still
possible that an app is bound to multiple instances with the same tag.

I have seen many apps that scan VCAP_SERVICES for a service with
specific properties and pick the first match. This is error prone as there
could be multiple matches.



So I think binding names would be more explicit and tags seem more like
a workaround.





On Mon, Mar 13, 2017 at 9:22 PM, Greg Cobb <gcobb(a)pivotal.io> wrote:

One can supply arbitrary tags for service instances: https://apidocs.clo
udfoundry.org/253/service_instances/creating_a_service_instance.html.
This is not at the binding level, but you could tag your instances as
"secure" and filter on that. Does this help your use case?



On Sun, Mar 12, 2017 at 5:04 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

This is a great idea. Today to get around this issue my org names our
service instances with a #value at the end and we use custom VCAP_SERVICES
client libraries to ignore anything after the #. That allows us to have a
service named oracle-db#dev and oracle-db#test both be found in
configuration with the name "oracle-db". This proposal would fix that
issue for my org.



Mike



On Sun, Mar 12, 2017 at 4:02 PM, Peter Dotchev <dotchev(a)gmail.com>
wrote:

Hi,



Selecting the right service binding from application code in Cloud
Foundry is often ambiguous and error prone. To address this, I propose to
introduce a service binding name.



The proposal is described in details here

https://github.com/dotchev/cf-named-binding



Looking forward to your comments.



Best regards,

Peter








Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.