Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Creating CF Services

101 views
Skip to first unread message

brando...@newwave-technologies.com

unread,
Feb 14, 2014, 9:14:32 AM2/14/14
to vcap...@cloudfoundry.org
Hi all,

I'm running v149 on OpenStack, and I'm attempting to launch a mongodb service from the cf-services-contrib package, release version 3. I can successfully create a service auth token, and the CC connects and reads the default plan from the gateway into the catalog. But when I try and create a service, it hangs, then tells me

"CFoundry::BadResponse: 502: 502 Bad Gateway: Registered endpoint failed to handle the request." 

I've looked at the gateway logs during the operation and I think it has something to do with the NATS but I'm not sure what's misconfigured here. I've pasted both my manifests and the relevant error snippet. Any help would be much appreciated. Thanks.





Brandon

ramonskie

unread,
Feb 17, 2014, 9:52:51 AM2/17/14
to vcap...@cloudfoundry.org
maby the same error i got?
https://github.com/cloudfoundry-community/cf-services-contrib-release/issues/109

but my problem was that bosh would even finish the deployment.
but maby it helps you to :)

Op vrijdag 14 februari 2014 15:14:32 UTC+1 schreef brando...@newwave-technologies.com:

brando...@newwave-technologies.com

unread,
Feb 17, 2014, 8:29:27 PM2/17/14
to vcap...@cloudfoundry.org
Tried that, didn't solve anything. Pretty sure the error is with NATS authentication, but I don't know where to start with that honestly. Thanks though.

James Bayer

unread,
Feb 17, 2014, 10:59:24 PM2/17/14
to vcap...@cloudfoundry.org
i don't think it's NATS authentication, at least based on this message:

CCNG Catalog Manager: Failed to get currently advertized offerings from cc: #<RuntimeError: CCNG Catalog Manager: - Multiple page fetch via: /v2/services?inline-relations-depth=2

so i think that's the call from the ServiceBroker to the Cloud Controller. hopefully shannon coen has an idea.  


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

unread,
Feb 18, 2014, 5:08:22 PM2/18/14
to vcap...@cloudfoundry.org
I saw the same thing James did. Looks like the fetch to cc on /v2/services is failing for some reason. But it isn't clear that this is even related to the failed create-service operation. Since you did get the catalog written to cc, let's focus on the service create failure. 

Using the ruby cli (http://rubygems.org/gems/cf), run your create-service command with trace enabled (-t). The command will make several API calls. For the last call, to /v2/service_instances, look for the the x-vcap-request-id (value is a guid). 

Grep both cc logs and the broker log with this request id and post a gist here. 

Thanks,
Shannon

brando...@newwave-technologies.com

unread,
Feb 19, 2014, 10:32:51 PM2/19/14
to vcap...@cloudfoundry.org
So this is the grep from the cloud controller


and this is the cf create-service -t


Nothing came up when I searched the mongo gateway logs

Shannon Coen

unread,
Feb 24, 2014, 2:27:35 PM2/24/14
to vcap...@cloudfoundry.org
Thanks, but it doesn't look like you're getting a x-vcap-request-id to grep the logs with. This guid would give you the full conversation, from request from the client, to a call to the broker, and response from the broker. From your trace, I'm wondering if there's an issue with your cc. It may be that cc isn't even getting as far as making a call to the broker. 

Creating service p-mysql-82109>>>
REQUEST_HEADERS:
  Accept : application/json
  Authorization : [PRIVATE DATA HIDDEN]
  Content-Length : 135
  Content-Type : application/json
REQUEST_BODY: {"name":"p-mysql-82109","service_plan_guid":"b2138f35-44f9-44db-b712-c0c750495955","space_guid":"e300fceb-9f21-459e-bcc1-0a6e5068c642"}
.  RESPONSE: [201]
RESPONSE_HEADERS:
  connection : keep-alive
  content-length : 836
  content-type : application/json;charset=utf-8
  date : Mon, 24 Feb 2014 18:59:28 GMT
  location : /v2/service_instances/809e0a0a-3b96-478a-9894-abbf35a20543
  server : nginx
  x-content-type-options : nosniff
  x-vcap-request-id : bb248278-a40c-428c-bf48-e26add7d6668

Without a request ID to work with, I would grep the cc logs for something unique about the request, maybe the name you gave to the service instance. You may find the vcap-request-id associated with the request from the client, even though cc isn't returning it to the client. Then you can grep the logs for it and see the whole conversation. See if CC can tell you more about why it is returning a 502. 
Reply all
Reply to author
Forward
0 new messages