Hi, I'm experiencing a weird situation where api and api_worker jobs fail to update through bosh and end up being reported as "not running". However, manually running "monit start

I have a small environment with old version as 183 It only has one DEA, having couple apps running on that, it suddenly stop working when deploying apps (staging) without any obvious error and

Try telling BOSH to ignore what AZ the server is in when provisioning disks: https://github.com/cloudfoundry/bosh/blob/master/release/jobs/director/spec#L395 It will default to cinders default AZ

Hi, I am trying to deploy cf into Openstack with multiple computing nodes. Computer node 1: has all openstack services running, including cinder service (az1) Computer node 2: has computing

The cf-release v210 was released on May 23rd, 2015 Runtime - Addressed USN-2617-1 <http://www.ubuntu.com/usn/usn-2617-1/> CVE-2015-3202

Thanks Ivan! That is exactly what I was looking for.

For all the loggregator processes, you will be able to find their configuration properties in their respective spec and ERB files in

Hi all, I've been trying to figure out an issue here while upgrading to 210 from 208. It seems that a requirement has been added to the deployment manifests for a "metron_agent.deployment" property

This Java native memory leak debugging war story from a Twitter engineer is very interesting: http://www.evanjones.ca/java-native-leak-bug.html Tweet is

Hello all, As a follow on to the original notice [1], I wanted to clarify that we plan to remove the lucid64 stack from cf-release with the next final cf-release that we hope to make available in the

Ive only had a brief look, my graphite server does not seem to have the same set of stats for each dea and doppler node, but where i can draw a comparison is that the dopplers in z2 and 3 are

I also don't expect that to be the source of your CPU imbalance. Well, the bad news is that the easy stuff checks out, so I have no idea what's actually wrong. I'll keep suggesting diagnostics, but I

- From etcd I see 5 unique entries, all 5 doppler hosts are listed with the correct zone - All metron_agent.json files list the correct zone name - All doppler.json files also contain the

John, Can you verify (on, say one runner in each of your zones) that Metron's local configuration has the correct zone? (Look in /var/vcap/jobs/metron_agent/config/metron.json.) Can you also verify

We are using cf v204 and all loggregators are the same size and config (other than zone). The distribution of requests across app instances is fairly even as far as I can see. John.

Diego is very much usable at this point and we're encouraging beta testers to start putting workloads on it. Check out github.com/cloudfoundry-incubator/diego for all things Diego. Diego supports

Another question, what is the status of Diego? Is there an expected date for its release? Is it useable already? If I understand correctly, Diego doesn't supports cron-like jobs, but will facilitate

those are exciting use cases, thank you for sharing the background! wrote: -- Thank you, James Bayer

I've asked the admin team to make this adjustment. Thanks for pointing this out! Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation

Thank you for the quick response, Dieu! -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-CVE-2015-1834-CC-Path-Traversal-vulnerability-tp163p176.html Sent from the CF Dev