cli
cli copied to clipboard
cf service should display instance and binding parameters
What's the user value of this feature request?
As a developer, in order to check which arbitrary params were provided to cf create-service -c ...
and cf bind-service -c
, I need the cf service
to display service instance parameters if any and each service binding parameters if any.
Who is the functionality for?
Application developers
How often will this functionality be used by the user?
As often as they use -c option in cf create-service
Who else is affected by the change? This feature is not a breaking change if added with care to avoid breaking line-based parsing of cf service output (i.e. add it to new lines)
Is your feature request related to a problem? Please describe.
As a user needing to check service instance and service binding params, I'm frustrated to have to use cf curl /v2/service_instances/$(cf service myservice --guid)/parameters
to display service instance params, and cf curl /v2/service_bindings/$(cf service myservice --guid)/parameters
to display service instance bindings.
Fetching service instance params was contributed by sapi in https://www.pivotaltracker.com/story/show/153739004
Describe the solution you'd like
A built-in support for displaying arbitrary params, that were provisionned with the cli using -c flag.
Describe alternatives you've considered cf curl
/CC @addytripathi
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/170000142
The labels on this github issue will be updated when the story is started.
We're also interested in being able to report params back to users after service creation. Our primary use case is for services with config that is automatically set that users may be interested in. As an example, we have a broker that creates AWS RDS instances. Since we enable automatic minor version updates, we'd like users to be able to discover the postgres/mysql versions they're running.
Hi @FelisiaM - I saw **v8**
in the title. This doesn't feel like a backward-incompatible change. Could this be done without cutting a new major version?
Hey @tammersaleh,
We intend to implement this using v3 endpoints in the CLI. The v3 bindings endpoints are not yet released, so releasing this command using the them is considered a breaking change since it pushes the minimum version of CAPI that it's compatible with.