Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

label? #3

Closed
srl295 opened this issue Apr 14, 2015 · 6 comments
Closed

label? #3

srl295 opened this issue Apr 14, 2015 · 6 comments

Comments

@srl295
Copy link

srl295 commented Apr 14, 2015

should the VCAP label field be used as a selector? That tends to be fixed by the service provider.

@pmuellr
Copy link
Member

pmuellr commented Apr 14, 2015

Nope. As you say, the label is assigned by the service provider. So, what if you need to use two instances of a service - two databases, whatever. Would you just return the first? This becomes a particular problem with user-provided services, which all use the label 'user-provided' (or some such).

Also keep in mind that service labels have been known to change as services upgrade.

The service names, on the other hand, are assigned by the service creator; eg, you. You have complete control over the name. That's why the current getService...() methods search by name.

@srl295
Copy link
Author

srl295 commented Dec 23, 2015

So I hit this in the bug above — my own error, as getService* is documented as such.

However, in this case, I am the service creator, and I'm trying to make an SDK that will find the service instance properly.

Also keep in mind that service labels have been known to change as services upgrade.

Yes, but as the service creator, we have chosen a regex-matchable pattern that we will stick to for the service name.

So consider this a request for a new function, getServiceCredsByLabel() that will match a label.

@pmuellr
Copy link
Member

pmuellr commented Dec 24, 2015

Sounds reasonable. Feel free to create a PR with the new function, doc,
test cases, etc.

On Wed, Dec 23, 2015 at 3:19 PM, Steven R. Loomis notifications@github.com
wrote:

So I hit this in the bug above — my own error, as getService* is
documented as such.

However, in this case, I am the service creator, and I'm trying to make
an SDK that will find the service instance properly.

Also keep in mind that service labels have been known to change as
services upgrade.

Yes, but as the service creator, we have chosen a regex-matchable pattern
that we will stick to for the service name.

So consider this a request for a new function, getServiceCredsByLabel()
that will match a label.


Reply to this email directly or view it on GitHub
#3 (comment)
.

Patrick Mueller
http://muellerware.org

@srl295
Copy link
Author

srl295 commented Dec 24, 2015 via email

srl295 added a commit to IBM-Cloud/gp-js-client that referenced this issue Jan 14, 2016
Fixes: #9

* add NO_UTIL_TEST parameter
* add a module lib/cfenv-credsbylabel.js
* note upstream issue cloudfoundry-community/node-cfenv#3
* (todo) update docs as well to note the label functionality
* bump version to 1.0.3
@jthomas
Copy link

jthomas commented Feb 7, 2016

+1 on getServiceCredsByLabel().
I was just looking to see if this had been raised.

@srl295
Copy link
Author

srl295 commented Feb 8, 2016

srl295 added a commit to srl295/node-cfenv that referenced this issue Apr 11, 2016
getServiceCredsByLabel is like getServiceCreds except that the label is used.
* internal function getServiceByLabel added
* docs update
* tests update

Note, other get*ByLabel functions may be desired. This is just a starting point.

See discussion cloudfoundry-community#3
srl295 added a commit to srl295/node-cfenv that referenced this issue Feb 2, 2017
getServiceCredsByLabel is like getServiceCreds except that the label is used.
* internal function getServiceByLabel added
* docs update
* tests update

Note, other get*ByLabel functions may be desired. This is just a starting point.

See discussion cloudfoundry-community#3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants