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
 so a stale value following a renaming had not much impact.
On Wed, Aug 9, 2017 at 9:40 PM, Sascha Matzke <sascha.matzke(a)didolo.org>
We've refrained from renaming and extended the service catalog of affected
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
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
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
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.
Product Manager, Cloud Foundry
Through the darkness of future past
the magician longs to see
One chants out between two worlds
*Fire walk with me*.