1. Topics
  2. Proposal for named service bindings

Proposal for named service bindings

Peter Dotchev <dotchev@...>
 

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

?
attachment.html

Mike Youngstrom <youngm@...>
 

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

?
attachment.html

Greg Cobb
 

One can supply arbitrary tags for service instances:
https://apidocs.cloudfoundry.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

?
attachment.html

Mike Youngstrom <youngm@...>
 

You're right, tags could work. But, tags didn't exist when we created the
convention we have and doesn't seem much of an improvement much over our
existing solution. I don't believe our primary client library, spring
boot, supports using tags in such a way and users could still
?accidentally? and perhaps less obviously bind multiple services with the
same tag to a single app. Granted, using tags would put us on better
ground to contribute a solution to a client library, but the minimal
improvement didn't seem worth the effort to move our organization over to a
different convention.

On the other hand, this solution seems more purpose built for our use case
and would be more worth the effort of moving our organization in this
direction.

Mike

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

One can supply arbitrary tags for service instances: https://apidocs.
cloudfoundry.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

?
attachment.html

Peter Dotchev <dotchev@...>
 

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.
cloudfoundry.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

?
attachment.html

Koper, Dies <diesk@...>
 

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<mailto:gcobb(a)pivotal.io>> wrote:
One can supply arbitrary tags for service instances: https://apidocs.cloudfoundry.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<mailto: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<mailto: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

?
attachment.html

Peter Dotchev <dotchev@...>
 

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.
cloudfoundry.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








?
attachment.html

Peter Dotchev <dotchev@...>
 

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








?
attachment.html

Mike Youngstrom <youngm@...>
 

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








?
attachment.html

Nikolay Valchev
 

This is a real problem that we face in some of our apps as well. We’ve addressed it with the app environment variable configuration to tell the purpose of each service instance. Such approach works, but the solution in this proposal is more elegant. The only thing that bothers me is that in most cases the named binding might not be needed and thus should be better an optional CLI argument, which if missing might be populated by the service name as default value.

Nikolay

From: Mike Youngstrom <youngm(a)gmail.com>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Saturday, April 1, 2017 at 18:45
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Proposal for named service bindings

The proposal still has my vote FWIW. :)

Mike

On Sat, Apr 1, 2017 at 7:11 AM, Peter Dotchev <dotchev(a)gmail.com<mailto: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<mailto: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<mailto: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<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<mailto:gcobb(a)pivotal.io>> wrote:
One can supply arbitrary tags for service instances: https://apidocs.cloudfoundry.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<mailto: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<mailto: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

?
attachment.html

Zach Robinson
 

Hey Peter,

I like the use-case that this proposal allows developers to set their expected service name at development time. I think this is a nice explicit contract and is also portable between Foundations, where services may have different names.

I prefer that we find a way to keep VCAP_SERVICES backwards compatible and that we keep binding names optional.

I will try drop a doc off on this thread in a couple days with a proposal based on yours and with some cli stuff vetted by the cli team. Then we can look at getting work prioritized

-Zach
CAPI Project Lead
Mike Youngstrom <youngm@...>
 

Excellent. Thanks Zack!

Mike

On Fri, Apr 14, 2017 at 5:54 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hey Peter,

I like the use-case that this proposal allows developers to set their
expected service name at development time. I think this is a nice explicit
contract and is also portable between Foundations, where services may have
different names.

I prefer that we find a way to keep VCAP_SERVICES backwards compatible and
that we keep binding names optional.

I will try drop a doc off on this thread in a couple days with a proposal
based on yours and with some cli stuff vetted by the cli team. Then we can
look at getting work prioritized

-Zach
CAPI Project Lead

?
attachment.html

Peter Dotchev <dotchev@...>
 

Hi Zach,

I am glad you find this idea useful too.
Let me know if you need further input.

Happy Easter!
Peter

On Sat, Apr 15, 2017 at 2:55 AM Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hey Peter,

I like the use-case that this proposal allows developers to set their
expected service name at development time. I think this is a nice explicit
contract and is also portable between Foundations, where services may have
different names.

I prefer that we find a way to keep VCAP_SERVICES backwards compatible and
that we keep binding names optional.

I will try drop a doc off on this thread in a couple days with a proposal
based on yours and with some cli stuff vetted by the cli team. Then we can
look at getting work prioritized

-Zach
CAPI Project Lead

?
attachment.html

Zach Robinson
 

Mike Youngstrom <youngm@...>
 

This looks great! Thanks Zach.

Mike

On Mon, May 8, 2017 at 12:05 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hey all,

Here's the implementation proposal: https://docs.google.com/
document/d/1PjcEx5_w383AKI9WyJHI4gGDkhIS9mhqwUK5nvmOWUc/edit?usp=sharing

And here's the tracker epic: https://www.pivotaltracker.
com/epic/show/3472063

-Zach

?
attachment.html

1 - 15 of 15