Right. So to restate this discussion only applies to buildpack containers docker containers currently are and will continue to be run in unprivileged mode by default. Correct?

Hey Mike, Just to be clear, I think you have a (consistent) sign error throughout your e-mail? Cloud Controller's current behavior is to request *un*privileged (i.e. "more secure") containers for

Thanks Will. Would other existing limits (e.g. nice, or fair cpu share) prevent one app from using up all of the host disk io, or could such app impact its neighbor containers (and other DEA/Cell

Good description. Count us as one who does not use FUSE and would very much like to run docker images in privileged mode. Perhaps it would be appropriate to force privileged mode for docker apps but

The buildpack set event is, essentially, a metadata event. It records the buildpack that was used to stage an application. This information could not be included in the started event because

The old vcap-dev mailing list had a number of exchanges around this topic that you might want to look at. The basic gist is that linux gives processes that are not associated with a cgroup a cpu

Thanks Julian and Onsi for the additional details. Much clearer now. Guillaume.

To that I would add that privileged: true is the behavior of the existing platform and warden. Sticking with privileged: true essentially opts you out off gardens new security features. So running

Hi Guillaume, I'd put it like this: running containers with 'privileged: false' makes them safe /even if/ a user gets root. With a docker image this is essential, because getting root is trivial. With

Hi Guillaume, No, Garden-Linux does not currently do any disk IO limiting. Thanks, Will

I'm pleased to announce the release of the java-buildpack, version 3.1.1. This release ensures that the dependencies contained in the offline buildpack are up to date. For a more detailed look at the

Out of curiosity, I'd like to understand whether Garden is limiting disk IOs, similar to [2]. I do see disk space, inodes..., and network IOs limits described into [1] but did not find block

Thanks Onsi. Being able to use FUSE is quite important to us too. Can you clarify the security risk associated with running a privileged container (as a workaround for the lack of fuse support within

Eric, The CAB minutes [1] mentionned you were still looking for feedback from the community on the policy for altered instances, but this thread seems silent for a while. Not sure you had seen my

Thanks Mike, this is now in the wiki https://github.com/cloudfoundry-community/cf-docs-contrib/wiki Guillaume.

Thanks again to Phil Whelan for crafting the greatly detailed cab minutes. http://www.activestate.com/blog/2015/07/cloud-foundry-advisory-board-meeting-2015-july The MEGA section says the

Sorry all, The correct URL for LicenseFinder tracker is: https://www.pivotaltracker.com/n/projects/234851 However, the Toolsmiths tracker is private as there's quite a bit of work in there that's

Mike, not sure you had seen my question to the utilities pointers below ?

Hi, I wonder if there are plans to implement an auto-sleep behavior in cloudfoundry, in which inactive apps would be automatically stopped after a max inactivity threshold, and automatically restart

Thanks Shannon for your feedback. I understand there is a small window into which the pre-determined app might not exist anymore (e.g. during blue/green deployment traffic shift). The default