Hey Dan, Have you been able to confirm that this occurs on CF v219 and not on earlier versions of CF? What's the earliest version of CF where you're seeing this behavior? Thanks, Natalie & Mikhail OSS

Org and Service Instance guids are generated by the Cloud Controller. It simply uses the SecureRandom.uuid ruby method: http://docs.ruby-lang.org/en/2.2.0/SecureRandom.html#method-c-uuid SecureRandom.

Hi Rohit, Here's a previous message about how the memory is calculated: https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/4R7ZBK6PL3HS2M6IMR2S745TWY4S6TIN/ Joseph &

Are you using an aws elb or a ha_proxy instance for your load balancer? If you curl api.SYSTEM_DOMAIN/v2/info, what is the logging_endpoint from the response? Joseph CF Release Integration Team tassin

The "instances" attribute from the api will give the current number of instances that should be running. If a user has recently changed this via the API, the actual number of running instances may be

I'd like to add as well that you can configure Bosh's healthmonitor to send this data to an external dataviz/archival service (we use Datadog for our various test environments): https://bosh.io/docs/h

This information is not provided to the app. You can see what data is provided here: http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#instance-vars If you want to get this inf

Droplets are important, and should not be removed. If an app is deleted, the droplet will also be deleted. If a droplet exists, that means it is still needed. If the app needs to be scaled up or moved

cf-release v213 fixed a bug where buildpack caches were not getting cleaned up properly. Are you running a version prior to 213? If so, you might need to go into the `shared/run.10.10.2.37.xip.io-cc-d

You can also check out the v208 tag of cf-release, then run the acceptance-tests from src/github.com/cloudfoundry/cf-acceptance-tests Joseph CF Release Integration Team wrote:

Containers have a default iptables rule for REJECT all traffic. If there is not a security group configured to allow the traffic to the destination, you'll get a connection refused. Security groups ca

This definitely sounds like a security groups issue, Do you have an progress on this? Zak & Mikhail, CF Release Integration

Hey Kyle, Did you make any progress? Zak & Mikhail CF Release Integration Team

Hmm, BOSH has functionality for adding the certificate to all the deployed VMs: https://bosh.io/docs/trusted-certs.html I'm not sure if the Warden containers will use the system certificate store thou

The API doesn't have a concept of default shared domain currently. You are correct that the cf CLI simply takes the first shared domain and uses it when developers do a `cf push`. Deleting the old dom

The Warden logs (and possibly the DEA logs) would probably be helpful in figuring out what is going on there. Joseph CF Release Integration Team kyhavlov(a)cisco.com> wrote:

It certainly could be. By default the contains reject all egress traffic. CC security groups configure iptables rules that allow traffic out. One of the default security groups in the BOSH templates a

A lot of this is set to change in the near future to make things more clear. But here is what is currently going on. BOSH will pre-create machines it is going to need, and it does that without any inp

Also worth noting: if you're cloning from the ssh endpoint at github you must have an ssh key in your ssh agent that authenticates against a real github user, even if the repo is public. It seems as t

The DEAs are responsible for broadcasting the routes for the apps they are running. I can't think of why an hm9000 problem would cause routes to get lost, unless there was some problem with NATS itsel