Date
1 - 15 of 15
Proposal for named service bindings
|
Mike Youngstrom <youngm@...>
This looks great! Thanks Zach.
toggle quoted message
Show quoted text
Mike On Mon, May 8, 2017 at 12:05 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:
Hey all, |
|
|
|
Zach Robinson
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 |
|
|
|
Peter Dotchev <dotchev@...>
Hi Zach,
toggle quoted message
Show quoted text
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, |
|
|
|
Mike Youngstrom <youngm@...>
Excellent. Thanks Zack!
toggle quoted message
Show quoted text
Mike On Fri, Apr 14, 2017 at 5:54 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:
Hey Peter, |
|
|
|
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 |
|
|
|
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.
toggle quoted message
Show quoted text
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 |
|
|
|
Mike Youngstrom <youngm@...>
The proposal still has my vote FWIW. :)
toggle quoted message
Show quoted text
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: |
|
|
|
Peter Dotchev <dotchev@...>
The approach with tags has some issues too:
toggle quoted message
Show quoted text
- 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. |
|
|
|
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 itto a new app, can you add the tag expected by that app to the existing |
|
|
|
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 |
|
|
|
Peter Dotchev <dotchev@...>
Yes, tags at service instance level could work.
toggle quoted message
Show quoted text
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. |
|
|
|
Mike Youngstrom <youngm@...>
You're right, tags could work. But, tags didn't exist when we created the
toggle quoted message
Show quoted text
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. |
|
|
|
Greg Cobb
One can supply arbitrary tags for service instances:
toggle quoted message
Show quoted text
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 |
|
|
|
Mike Youngstrom <youngm@...>
This is a great idea. Today to get around this issue my org names our
toggle quoted message
Show quoted text
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, |
|
|
|
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 |
|
|