FYI... Tomorrow 8AM Pacific or 3PM UTC. Zoom soon. Best, dr.max ibm ☁ silicon valley, ca dr.max ibm ☁ silicon valley, ca

Thanks Dan - It's a reasonable guess! Following link has some explanation about why it has not worked on Diego - (The documentation of cf restart-app-instance should have this

Hi Has CF UAA code been developed in a way that is protected against potential SQL injections? Thanks Enrique

I'd guess that it's because you don't ever want to have an inconsistent state across your app instances. If you were able to use `cf restart-app-instance` and see this change then you'd have one app

Rescheduling the call from this week to next week due to travel in Asia. The team working on the "containerize CFAR control plane" effort would like to demo their efforts during the next call. Public

Hello everyone ! I am observing that the new environment variable set to my application using cf set-env is not getting reflected in the container even after cf restart-app-instance is done. Why is it

The Java Buildpack treats the Buildpack cache as an opaque directory. This means that there are larger system policies about whether it's cached per-cell, per-foundation, etc. but from the

The system buildpacks are cached on the cell and bind mounted read-only into each staging container. Buildpack URLs (to a git repo or a zip file) are downloaded every time staging occurs.

Thanks for the explanation. I have one more question: Is there any caching for the buildpack itself? The CC coding looks like the buildpack is downloaded for each staging operation (either as zip

Great news, thans a lot for the update Matt! Am Mo., 18. Juni 2018 um 12:22 Uhr schrieb Matt McNeeney <mmcneeney@...>: -- Freundliche Grüsse Lukas Lehmann

Hey Lukas, Thanks for checking in! We have had further feedback from users who have been trying out this feature and so far of the feedback has been very positive. Given that, we are likely to look

Hi Matt, Just wanted to check back if there is something we can help to make this feature GA? Did you get any further feedback within the last month? Best regards, Lukas Am Mi., 16. Mai 2018 um 13:15

Hi all, The CF CLI app display feedback survey will close today; if you haven't had a chance to take the short survey, we would appreciate your feedback. Thanks! Best, Abby

Hi All, We are planning to end support for version 2.x of the Cloud Foundry Java Client on December 31st, 2018. Updates will continue until then, but we recommend all users upgrade [0] to 3.x early.

If you're a Cloud Foundry meetup organizer (or a frequent speaker at Cloud Foundry meetups), can you please connect with me directly via email or slack? Thank you, -- ​Swarna Podila ​Senior

Hi Stephan, The buildpack cache (aka "app cache," or "build artifacts cache") is a per-app cache that is stored as a tarball in the blob store and recovered when an existing app is restaged

We cut routing release 0.179.0 yesterday with a bug fix for an issue where backends were not being pruned on a TLS handshake failure potentially leading to stale routes in the routing tables, now

Thanks, Aaron. A couple of notes: The Garden Windows team has started working on contributing to the Envoy Windows support. We're betting on this as the most likely path forward for data-in-motion

Just to close on this Microsoft has confirmed that this is expected for now, using IPSec along with WinNAT is not supported in 1709, 1803, or the upcoming Windows Server 2019. They are considering it

Hi, is there documentation available that describes how the buildpack cache works? I found the following info: https://docs.cloudfoundry.org/concepts/how-applications-are-staged.html “The