How to see the contents of a user-provided service?

[kevin...@gmail.com]

I'm new to cloud foundry and taking over a configuration that was set up by someone else. I want to inspect the contents of several user-provided services, to see what values are stored in each one. But the docs here only tell you how to see ALL the env values bound for an app. I want to be able to display what is in just ONE of the particular user-provided services.

[James Bayer]

you can do this with the rest api.

CF_TRACE=true cf service NAME_OF_SERVICE

for me i have an example like:

CF_TRACE=true cf service oracle-db-mine

then take the URL value that comes out and use "cf curl" like this and the credentials value should show just that service, which are username and password in the below example:

cf curl /v2/user_provided_service_instances/6bc353a0-bf3f-4bbc-844f-d12b9fe7bfb8

{

   "metadata": {

      "guid": "6bc353a0-bf3f-4bbc-844f-d12b9fe7bfb8",

      "url": "/v2/user_provided_service_instances/6bc353a0-bf3f-4bbc-844f-d12b9fe7bfb8",

      "created_at": "2014-07-14T19:59:31+00:00",

      "updated_at": null

   },

   "entity": {

      "name": "oracle-db-mine",

      "credentials": {

         "password": "pa55woRD",

         "username": "admin"

      },

      "space_guid": "6c8d0e5b-a3bc-4e80-ae4e-b51c88bf9fe0",

      "type": "user_provided_service_instance",

      "syslog_drain_url": "",

      "space_url": "/v2/spaces/6c8d0e5b-a3bc-4e80-ae4e-b51c88bf9fe0",

      "service_bindings_url": "/v2/user_provided_service_instances/6bc353a0-bf3f-4bbc-844f-d12b9fe7bfb8/service_bindings"

   }

}

On Sun, Nov 23, 2014 at 4:04 PM, <kevin...@gmail.com> wrote:

I'm new to cloud foundry and taking over a configuration that was set up by someone else. I want to inspect the contents of several user-provided services, to see what values are stored in each one. But the docs here only tell you how to see ALL the env values bound for an app. I want to be able to display what is in just ONE of the particular user-provided services.

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/d34cbfcf-8ef1-42d7-955d-11ce08feb8ab%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

Thank you,

James Bayer

[Shannon Coen]

If the user provided service instances are bound to an app, you can get the credentials by inspecting the environment variables for the app:

cf env my app

[Kevin Pauli]

Thanks Shannon, but there are some services that are not bound to any app.  It seemed silly to bind them to an app just so I could see what was in them.  :)   I will try James' suggestion.  

Probably would be a nice thing to add to the cli at some point.

On Mon, Nov 24, 2014 at 10:00 AM, Shannon Coen <sc...@pivotal.io> wrote:

If the user provided service instances are bound to an app, you can get the credentials by inspecting the environment variables for the app:

cf env my app

--
You received this message because you are subscribed to a topic in the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/a6a7b385-1885-4809-9cfb-2d99de745614%40cloudfoundry.org.

--

Regards,

Kevin Pauli

[Patrick Mueller]

On Wed, Nov 26, 2014 at 11:29 AM, Kevin Pauli <ke...@thepaulis.com> wrote:

Thanks Shannon, but there are some services that are not bound to any app.  It seemed silly to bind them to an app just so I could see what was in them.  :)   I will try James' suggestion.  

Ya, we're seeing that as well.  Some services' credentials are essentially "fixed" after creation, and it would be nice to be able to see those credentials - having easy access to them - without having them being bound to an essentially useless app (app created JUST to bind services to, to get their credentials).

This is particularly true for user-provided services, whose credentials will never change after created - or `cf update-user-provided-service`'d.

Currently, these are the CLI operations available against user-provided services:

Create - `cf create-user-provided-service ...`

Read - nuthin'

Update - `cf update-user-provided-service ...`

Delete - `cf delete-service ...`

We need CRUD, but we only have CUD.  Whatever the `read` operation is, it should also operate against non-user-provided-services whose credentials are known to be fixed after creation, as an added bonus :-).

I think the `read` operation would be named `cf user-provided-service ...`, in keeping with the same scheme for CLI apps and services operations.  I don't think a `cf user-provided-services ...` is needed, because `cf services` already handles this.

I think I've already mentioned that `cf update-user-provided-service ...` should take just a list of property names, like `cf create-user-provided-service ...` does - presumably, prompting the user for the new value of the property. Would be nice to have the arguments work the same for both commands.