Date
1 - 6 of 6
Service broker authors: have you ever changed your service or plan names?
|
Shannon Coen
The Service Broker API currently supports modifying the service name and
plan name fields, as a uuid is used as the unique identifier. These names are used in CLI workflows, and are used by applications to parse the VCAP_SERVICES environment variable to identify credentials. In practice, if these names are changed it may require updating an application to use the new service name to identify credentials. The metadata field is often used to expose display names for services and plans. The Open Service Broker API working group is interested to know how often these names actually change, and whether they could be considered immutable in the future. Best, Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc.
|
|
|
|
Mike Youngstrom <youngm@...>
We have renamed plans and services in the past. I would like to be able to
toggle quoted messageShow quoted text
continue to update them in the future. But I wouldn't consider it a must have feature but it does has come in handy in the past. Mike
On Tue, Aug 8, 2017 at 3:58 PM, Shannon Coen <scoen(a)pivotal.io> wrote:
The Service Broker API currently supports modifying the service name and
|
|
|
|
Subhankar Chattopadhyay <subho.atg@...>
It would be good to have plan renaming feature, also would be good to
toggle quoted messageShow quoted text
have it only as display name so that it can be changed without much of dependency. We have also faced similar situations previously.
On Wed, Aug 9, 2017 at 3:40 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:
We have renamed plans and services in the past. I would like to be able to --
Subhankar Chattopadhyay Bangalore, India
|
|
|
|
Sascha Matzke
We've refrained from renaming and extended the service catalog of affected
toggle quoted messageShow quoted text
brokers with additional "new" entries with new names and UUIDs and actively phased out the old ones (restricted access etc.). There are so many delicate mechanisms bound to the names of marketplace services (triggers in buildpacks, spring cloud magic) that renaming existing services seemed to risky. A clearer contract about how to handle service and service plan names would definitely help (are the names just display names or is it ok to use them otherwise). Best, Sascha
On Tue, Aug 8, 2017 at 11:58 PM, Shannon Coen <scoen(a)pivotal.io> wrote:
The Service Broker API currently supports modifying the service name and --
Through the darkness of future past the magician longs to see One chants out between two worlds *Fire walk with me*.
|
|
|
|
Hi Shannon,
We have occasionally renamed service plan names in the past. For example, we introduced a new experimental service and named the plan "alpha" (in addition to the plan description detailing the alpha semantics). When we managed to improve quality of service for this experimental service without requiring users involvement (such as rebinds or creating new service instance), then we renamed the "alpha" plan into "default". Most of our applications don't leverage the "plan" key in the VCAP_SERVICES [1] so a stale value following a renaming had not much impact. [1] http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#VCAP-SERVICES Guillaume. On Wed, Aug 9, 2017 at 9:40 PM, Sascha Matzke <sascha.matzke(a)didolo.org> wrote: We've refrained from renaming and extended the service catalog of affected
|
|
|
|
Ketaki Gadre <kets.gadre@...>
We have renamed plans for services in the past and will be good to have
toggle quoted messageShow quoted text
feature. As already mentioned, a proper contract to handle such service plan names renaming would definitely help.
On Thu, Aug 17, 2017 at 5:54 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:
Hi Shannon,
|
|
|