Sridhar, Thanks for your response. I found the VM is listening to port 8500: root(a)c6822dcb-fb02-4858-ae5d-3ab45d593896:/var/vcap/sys/log# netstat -anp | grep LISTEN tcp 0 0

Hi Ponraj, I don't think the CC can make any determination regarding the validity of environment variables as the CC doesn't (and shouldn't) know how each buildpack will use these environment

Indeed, I've had great success using the `jq` command-line tool to parse JSON along with `cf app app-name --guid` and `cf curl`. Like so: $ cf curl /v2/apps/$(cf app app-name --guid)/stats | jq

Hi, Any inputs on the current behavior of the APIs would be of great help, thanks ! Regards, Padma This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential

Dear Padma, Mathias, all, BOSH has just included the functionality to replace all properties with the string "<redacted>" already *on the server side*. Maybe that is an option the Cloud Controller

It will be interesting if there are any solutions to handle this from CF. As an alternative solution, every client tools should build some logic to hide the secure variables. However, it will not be

The router_status endpoint of the router node gives a nice point-in-time snapshot of the IPs / ports in is for each app URL, in json, andis continually kept up to date by the CF platform.

Hi Wayne, Can you please verify port 8500 listening? Maybe output of netstat -anp will

cool. thanks for sharing this john! wrote: -- Thank you, James Bayer

I am able to ping that host: root(a)5f0f5c52-01a8-4cc4-afac-d6a25edd8dcc:/var/vcap/sys/log# ping -c 1 api.bosh-lite.com PING api.bosh-lite.com (10.244.0.34) 56(84) bytes of data. 64 bytes from

That's correct. You need that job, otherwise, the environment is unusable. Do you know which checklist you are following or using to install bosh-lite? any idea on host configuration-

Sridhar, Thanks for your response. I see the following in the log file: 2016/03/05 00:02:38 [crit] 5082#0: *3 connect() to unix:/var/vcap/sys/run/cloud_controller_ng/cloud_controller.sock failed

You don't have consul_agent colocated on your api_zN jobs, so they are not registering the cloud_controller_ng.service.cf-internal service, so DEA can't download droplets from the CCs. You can see

Hi Wayne, Below jobs are failing. You will find more details about the errors in below dir. /var/vcap/sys/logs/<job_name>/ Process 'cloud_controller_ng' Execution failed Process

I'm also very interested to hear about what you might need to do with direct container-to-container communication. We've started an effort to enable it at the network layer, and as Dan gets at,

Hi, I tried to deploy CF v231 and got the following error: Started updating job api_z1 > api_z1/0. Failed: `api_z1/0' is not running after update (00:03:09) The monit summary

Look at the environment variables in the container, things starting with VCAP_ or CF_ provide you with details about the container, app and bound services. It sounds like you're looking for

Thanks, that's all we need. https://github.com/cloudfoundry/uaa/issues/329

Filip, Further deep trace shows that a SCIM object containing phoneNumbers: null triggers the error, while phoneNumber: [] works Below is the full

Hi *, as you know cf env reveals much useful information. But it also reveals passwords and secrets. In many occasions I saw that people who used cf env did not think about the implications of