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

Hi James, thanks for the answer! We are interested to implement a job scheduler for CF. Do you think this could be interesting to have? We are working in a project called DC4Cities

Yes, that's the correct commit to cherry pick for the cc path traversal vulnerability. -Dieu CF Runtime PM

I understand the CFF strongly recommends to upgrade to v208 or after, but for those (including us) who cannot immediately upgrade, I want to know if there is a workaround against this

Hi John, I'll be working on this with engineering in the morning; thanks for the details thus far. This is puzzling: Metrons do not route traffic to dopplers outside their zone today. If all

Correct, thanks.

there is ongoing work to support process types using buildpacks, so that the same application codebase could be used for multiple different types of processes (web, worker, etc). once process types

To complete my request, I'm thinking of something like this in the manifest.yml: applications: - name: virusscan memory: 512M instances: 1 *schedule: - startFrom : a date

Hi guys, just to know, is there a project to add a job scheduler in Cloud Foundry? I'm thinking of something like the Heroku scheduler ( https://devcenter.heroku.com/articles/scheduler). That would be