cf enable-service-access error

[atul.ks...@gmail.com]

Hi,

We are trying to build service broker to provide managed services in pivotal CF. While we were able to push the service broker app and successfully register the service broker with CF, we are facing issues when enabling service access to the services provided by the service broker.

/v2/catalog API implementation by our service broker returns following data:

{
    "services":
        [
            {
                "id":"d68fd467-73fd-4942-8d1b-84fc49cd355b",
                "name":"myservice",
                "description":"My Service",
                "bindable":true,
                "plans":[
                    {
                        "id":"fe797b34-2d73-41cc-bec5-11e0df406866",
                        "name":"free",
                        "description":"This is a default plan.",
                        "free":true
                    }
                ],
                "tags":[],
                "metadata":{},
                "requires":[],
                "dashboard_client":null
            }
        ]
}

cf service-brokers cli shows following output:

Getting service brokers as admin...

name              url  
p-mysql           http://p-mysql.run.ice.ge.com:80  
docker            http://10.15.212.86  
myservice-sb      http://myservice-sb.apps.ice.ge.com  

cf service-access shows following output:

Getting service access as admin...
broker: p-mysql
   service   plan        access   orgs  
   p-mysql   100mb-dev   all        
   p-mysql   1gb-dev     all        

broker: docker
   service           plan    access   orgs  
   postgresql93      free    all        
   mysql56           free    all        
   redis28           free    all        
   mongodb26         free    all        
   couchdb16         free    all        
   neo4j21           free    all        
   arangodb22        free    all        
   rabbitmq33        free    all        
   memcached14       128Mb   all        
   memcached14       512Mb   all        
   memcached14       1Gb     all        
   elasticsearch13   free    all        
   logstash14        free    all        
   etcd              free    all        
   consul            free    all        
   rethinkdb         free    all        

broker: myservice-sb
   service       plan   access   orgs  
   myservice   free   none        

Since the service provided by our service broker is private, we are trying to give access to "all" by using following cf command:

cf enable-service-access myservice

However, we always get following error when we run this command:

$ cf enable-service-access myservice
Enabling access to all plans of service myservice for all orgs as admin...
FAILED
Server error, status code: 400, error code: 10005, message: The query parameter is invalid: service_plan_guid

Can someone please point us what we are missing?

I tried cf curl /v2/service_plans but the output doesn't show our service plan.

Thanks,
Atul

[Shannon Coen]

Hello Atul,

I believe the problem is that your version of cf-release may be old. The CLI depends on support for a query parameter that was added to the cloud controller API in cf-release 179. See the prerequisites for service access control here: http://docs.cloudfoundry.org/services/access-control.html.

If updating cf-release is not an option, you can use curl to accomplish your goal. You must be logged in as admin. 

1. Obtain the guid for the service

$ cf curl /v2/services?q=label:myservice

2. Obtain the guid for the service plan

$ cf curl /v2/service_plans?q=service_guid:<service guid>

3. Make the plan public

$ cf curl /v2/service_plans/<plan guid> -X PUT -d '{"public":true}'

[Greg Oehmen]

Yes, this issue was addressed via the fix for this bug [0].   The commit was included in CF CLI v6.5.1 [1] so you'll need to be on that release or newer to take advantage of enable-service-access via the CLI

Best

Greg

[0] https://www.pivotaltracker.com/story/show/77230024

[1] https://github.com/cloudfoundry/cli/releases/tag/v6.5.1

--
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/43fc463f-867b-4fc7-8630-461e9fac1727%40cloudfoundry.org.

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

[atul.ks...@gmail.com]

We were using cf-release 177 (2.8.0) with cf cli version 6.7.0. Once I used the curl commands you suggested I am able to make the service plan public.

Many thanks!

[Shannon Coen]

Greg, take a second look at the error:

The query parameter is invalid: service_plan_guid

We added support for this query param to the /v2/service_plan_visibilities endpoint in this story: https://www.pivotaltracker.com/story/show/76750428

I think the bug you referenced fixed an issue where the CLI incorrectly referred to this query parameter as `plan_guid`. It looks like the CLI version Atul is uses the correct query param, but cloud controller doesn't recognize it. For this reason I suspect they are using a new CLI and an older cf-release.

Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

--
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/CABbSAGRPHtnRkCF6LXSjk5jrBo6Eio7QnKneUskuFANC399nQA%40mail.gmail.com.

[Shannon Coen]

I've just issued a pull request to github.com/cloudfoundry/doc-services which adds the manual curl instructions back to the access control documentation. Should go live on the next prod docs push.

Best,

Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

--

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/1a3b9841-1b10-4a93-9177-77cc30d3b73f%40cloudfoundry.org.

[atul.ks...@gmail.com]

That will be awesome to have in the access control documentation.

--Atul