https://github.com/dingotiles/dingo-postgresql-release/releases/tag/v0.10.0 Dingo PostgreSQL is a "batteries included" service broker for Cloud Foundry that provisions dedicated highly available

Hi Rania, I found a Makefile in the spiff repo and learned that it's a go application: https://github.com/cloudfoundry-incubator/spiff/blob/master/Makefile So, you could build for windows env with

Hi Tomoe, We have moved along from this step and now stuck on step 4 while installing spiff in the below page: http://docs.cloudfoundry.org/deploying/boshlite/create_a_manifest.html we couldn't

Hi Rania, bin folder is in the bosh-lite repo[1] which you must have cloned to the host, not on the VM. [1]: https://github.com/cloudfoundry/bosh-lite/tree/master/bin Best, Tomoe

Answered in the github issue where this was copied from: https://github.com/cloudfoundry/cloud_controller_ng/issues/669#issuecomment-242437165 Nicholas Calugar Product Manager - Cloud Foundry

I think the problem was indeed related to issue 633. When I used another method to generate the rsa key pair for jwt (sadly the docs do not specify how this should be done) and deployed a new release

Example: api.example.com - [30/Aug/2016:19:39:20 +0000] "GET /v2/organizations?order-by=name HTTP/1.1" 500 195 "-" "go-cli 6.21.1+6fd3c9f / linux" 10.120.8.132, 10.120.7.14, 10.120.7.16

Yes, I see related requests in nginx_cc/nginx.access.log.

yes, I see related access requests in nginx_cc/nginx.access.log.

There has been no recreation of any VMs during this testing. The time span of the log file is within my tests. There is no 500 error and no matching ID. There is this issue that is

Look at the access log for Nginx. It's up a directory, `nginx_cc/access.log` (I think). Make sure that you see the request listed in the access log. The access log contains all incoming requests so

Did you recently `bosh recreate`, `bosh deploy` or has the resurrector recently recreated the VM (maybe check the uptime if you're unsure)? These are all things that can cause the VM to be rebuilt

Not just the one: [root(a)np-cloud-found01 ~]# bosh vms|grep api RSA 1024 bit CA certificates are loaded due to old openssl compatibility Acting as user 'admin' on 'my-bosh' | api_worker_z1/0

Do you have more than one api_zN instance running? Your logs may be on another VM.

And no ID in the file: grep 1730392b-7537-4a7c-7940-85e51faa1b7b cloud_controller_ng.log ; echo $? 1

There is nothing in that log for any organizations API query: pwd /var/vcap/sys/log/cloud_controller_ng ls -ltr total 16760 -rw-r----- 1 vcap vcap 239706 Aug 30 13:15

That would be the file. It should have more details. You can try searching on the vcap-request-id or you can look at the access log that nginx writes, look for the request to /v2/organizations

If you mean cloud_controller_ng.log on the api server, that file is unfortunately in unreadable json format. I see nothing in it returning a 500 error.

Look at your cloud controller logs. You should see some reason for the 500 error. That should give you more clues as to why it's failing. Dan

'CF_TRACE=true cf login -u admin' produces the output below. What might the problem be? REQUEST: [2016-08-30T13:07:02-04:00] GET /v2/organizations?order-by=name HTTP/1.1 Host: api.example.com Accept: