|
Re: Is Garden limiting disk IOs ?
Guillaume Berche
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 process), and possibly up to denial
of service (e.g. a compromised app that was to impact the cf platform that
host them) ?
Guillaume.
toggle quoted message
Show quoted text
On Thu, Jul 30, 2015 at 6:34 PM, Will Pragnell <wpragnell(a)pivotal.io> wrote: Hi Guillaume,
No, Garden-Linux does not currently do any disk IO limiting.
Thanks,
Will
On 30 July 2015 at 17:24, Guillaume Berche <bercheg(a)gmail.com> wrote:
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 IOs.
Thanks in advance,
Guillaume.
[1] http://godoc.org/github.com/cloudfoundry-incubator/garden
[2]
https://github.com/appc/spec/blob/master/spec/ace.md#resourceblock-bandwidth
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Removing FUSE support from CF
Mike Youngstrom <youngm@...>
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 allow running non privileged for non docker applications until FUSE can be removed? Mike On Thu, Jul 30, 2015 at 10:34 AM, Julian Friedman <julz.friedman(a)gmail.com> wrote: 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 a buildpack image this
is less essential, but it means /even if/ a root escalation exploit is
found (these do exist, there was an escalation via overlayfs patched a
while ago) you're still safe. 'Privileged: false' turns on user namespacing
and turns off various capabilities: it's what the Garden team recommend
most containers use. 'Privileged: true' relies on the security of your
rootfs and users never getting root; if your use case requires it you'll of
course need to make a judgement, but you're trading off quite a lot of
security in my opinion.
Sent from my iPhone
On 30 Jul 2015, at 17:12, Guillaume Berche <bercheg(a)gmail.com> wrote:
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 user
namespace), when pushing an app that goes through the buildpack staging
process (hence running as vcap user) ?
From http://godoc.org/github.com/cloudfoundry-incubator/garden I see
// If Privileged is true the container does not have a user namespace and the root user in the container
// is the same as the root user in the host. Otherwise, the container has a user namespace and the root
// user in the container is mapped to a non-root user in the host. Defaults to false.
Privileged bool <http://godoc.org/builtin#bool> `json:"privileged,omitempty"`
I understand the risk is specific to running a docker image built using
the docker file USER directive (specially root): then the container will
run as the host root ?
BTW, is the ability to run as a different user in staging and running
currently considered as discussed into
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/ZlC-2DVOSHo/uRrF6Io52mEJ
?
Thanks,
Guillaume.
On Thu, Jul 30, 2015 at 3:27 AM, Jack Cai <greensight(a)gmail.com> wrote:
+1 for space-level configuration.
Jack
On Wed, Jul 29, 2015 at 2:04 PM, Matt Cowger <matt(a)cowger.us> wrote:
We're wary of adding too many knobs to the platform and exposing them all the way down to app developers increases the cognitive load for folks
using the platform. Enabling/disabling it on a per-installation level, and
- maybe - a per-space level, might be a decent compromise?
Agreed. I'd argue this this probably not be a 'per-app' thing, as I too
amy way of the knobs that developers like to turn. I think a per space
level is just the right level.
On Wed, Jul 29, 2015 at 10:20 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
That's still very much open for discussion. Obviously, someone with
administrative privileges should be in charge of this particular piece of
configuration.
Also making this a runtime config (e.g. feature flag) as opposed to a
deploy-time config (e.g. part of the CC config written out by BOSH) would
make the different behaviors more testable.
Thoughts? Preferences? We're wary of adding too many knobs to the
platform and exposing them all the way down to app developers increases the
cognitive load for folks using the platform. Enabling/disabling it on a
per-installation level, and - maybe - a per-space level, might be a decent
compromise?
Onsi
On Wed, Jul 29, 2015 at 9:54 AM, Matt Cowger <matt(a)cowger.us> wrote:
Once - configurable on a per-app, per space, or per deployment basis?
On Wed, Jul 29, 2015 at 9:50 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
Hey all,
Based on the feedback we got and the relatively low cost to maintain
privileged support we'd like to propose making running privileged
containers on the platform configurable - we will recommend this be turned
off when running untrusted workloads and it will likely default to off. We
have longer term plans to support mounting persistent volumes in Diego at
which point support for mounting FUSE in unprivileged containers can become
a reality.
Thoughts?
Onsi
On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:
On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <
vedran.lerenc(a)sap.com> wrote:
Hi Onsi,
Ø Thoughts? Concerns?
Well, that’s bad news.
We, and I assume many others as well (like the folks from Stackato
who do it in the public), have used SSHFS + FUSE to implement a persistent
file system for old-fashioned apps/apps that are not Cloud-native. I don’t
want to fight an ideological battle here, it’s just that these apps do
still exist (in majority) and a file system service is an important
service/feature for them.
So if you remove FUSE (which we thought is not going away/was added
to stay), it’s pretty bad for us/many apps.
Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very
helpful for running apps that depend on a persistent FS, like Wordpress.
Perhaps this use case of mounting a remote SSHFS could be supported in some
other way?
Dan
*From: *Onsi Fakhouri
*Reply-To: *"Discussions about Cloud Foundry projects and the
system overall."
*Date: *Saturday 11 July 2015 01:10
*To: *cf-dev
*Subject: *[cf-dev] Removing FUSE support from CF
Hey CF-Dev,
The Garden team has been hard at work substantially improving
Garden-Linux's security features. Garden-Linux now employs user namespaces
and drops capabilities when creating unprivileged containers - we're
excited to bring both of these features to the platform!
Diego currently runs applications in *privileged* containers.
These lack the security features outlined above and we are planning on
switching to launch all CF applications in *unprivileged*
containers.
Unfortunately, it has proved difficult to support
mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are
planning on removing support for FUSE in favor of better securing our
containers.* If/when FUSE support in unprivileged containers
becomes possible we may add it back to the platform.
Thoughts? Concerns?
Thanks!
Onsi
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Questions about /v2/app_usage_events
Matthew Sykes <matthew.sykes@...>
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 staging
happens after the app is started.
toggle quoted message
Show quoted text
On Thu, Jul 30, 2015 at 5:46 AM, 王小锋 <zzuwxf(a)gmail.com> wrote: Hi, there
I noticed there are three state about the app event, started, stopped and
buildpack_set.
what does "buildpack_set" mean? If the app is in buildpack_set status,
does it occupy cup/memory/disk?
If the app is deleted, will the event reflected in app_usage_events? if
no, should I use /v2/app_usage_events together with
/v2/events?q=type:audit.app.delete-request to determine the lifetime of an
app?
Many thanks.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Matthew Sykes
matthew.sykes(a)gmail.com
|
|
|
Re: Default cgroup CPU share
Matthew Sykes <matthew.sykes@...>
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 share of 1024. That means that the code that runs the DEA and
all of the linux daemons that make things go will get that share.
When applications are placed on a DEA, the containers they run in are
associated with a cpu share that is proportional to the amount of memory
requested. If you request a lot of memory per app instance, you'll have a
high cpu share; if you request a little memory per app instance, you'll
have a low cpu share.
The cpu share values associated with the container cgroups will never be
allowed to exceed 1024 (to prevent applications from adversely impacting
the DEA processes).
These cpu share values really only start to impact things when there's
competition for the cpu. When that happens, processes in a cgroup that is
associated with higher shares will get more cpu than those with lower
shares.
There is no "limit" to the number of shares - they're treated as relative
values when the scheduler needs to make a choice. The goal is that, given
two processes A and B, if process A has a share weight that is twice that
of process B and both processes are cpu bound, process A will get twice as
many shares of the cpu as process A.
For a more complete understanding, you should read the documentation in the
linux tree for the scheduler.
toggle quoted message
Show quoted text
On Tue, Jul 28, 2015 at 8:11 PM, John Wong <gokoproject(a)gmail.com> wrote: I am reading
https://docs.cloudfoundry.org/concepts/architecture/warden.html#cpu and
it said:
If B is idle, A may receive up to all the CPU. Shares per cgroup range from 2 to 1024, with 1024 the default. Both Diego apps and DEA apps scale
the number of allocated shares linearly with the amount of memory, with an
app instance requesting 8G of memory getting the upper limit of 1024
shares. Diego also guarantees a minimum of 10 shares per app instance.
So 1024 is the default share every app get by default?
Say I start with an empty DEA.
APP #1: 1G shared = 1024?
APP #2 added. 1G shared =? what happen to APP #1?
APP #2 added: 512MB shared =? What happened to APP #1 & APP 2?
APP #3 added: 8GB, now what happened?
I am all assuming their usage is nearly idle. What is the total number of
share for a N-core DEA? Also are the shares dynamic? In the mean time I
will try to understand how CPU usage is shared in cgroup from other
resource.
Thanks.
John
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Matthew Sykes
matthew.sykes(a)gmail.com
|
|
|
Re: Removing FUSE support from CF
Guillaume Berche
Thanks Julian and Onsi for the additional details. Much clearer now.
Guillaume.
toggle quoted message
Show quoted text
On Thu, Jul 30, 2015 at 6:40 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io> wrote: 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 privileged containers isn't a step backwards. It's simply a
choice not to take a step forwards.
Onsi
On Jul 30, 2015, at 9:34 AM, Julian Friedman <julz.friedman(a)gmail.com>
wrote:
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 a buildpack image this
is less essential, but it means /even if/ a root escalation exploit is
found (these do exist, there was an escalation via overlayfs patched a
while ago) you're still safe. 'Privileged: false' turns on user namespacing
and turns off various capabilities: it's what the Garden team recommend
most containers use. 'Privileged: true' relies on the security of your
rootfs and users never getting root; if your use case requires it you'll of
course need to make a judgement, but you're trading off quite a lot of
security in my opinion.
Sent from my iPhone
On 30 Jul 2015, at 17:12, Guillaume Berche <bercheg(a)gmail.com> wrote:
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 user
namespace), when pushing an app that goes through the buildpack staging
process (hence running as vcap user) ?
From http://godoc.org/github.com/cloudfoundry-incubator/garden I see
// If Privileged is true the container does not have a user namespace and the root user in the container
// is the same as the root user in the host. Otherwise, the container has a user namespace and the root
// user in the container is mapped to a non-root user in the host. Defaults to false.
Privileged bool <http://godoc.org/builtin#bool> `json:"privileged,omitempty"`
I understand the risk is specific to running a docker image built using
the docker file USER directive (specially root): then the container will
run as the host root ?
BTW, is the ability to run as a different user in staging and running
currently considered as discussed into
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/ZlC-2DVOSHo/uRrF6Io52mEJ
?
Thanks,
Guillaume.
On Thu, Jul 30, 2015 at 3:27 AM, Jack Cai <greensight(a)gmail.com> wrote:
+1 for space-level configuration.
Jack
On Wed, Jul 29, 2015 at 2:04 PM, Matt Cowger <matt(a)cowger.us> wrote:
We're wary of adding too many knobs to the platform and exposing them all the way down to app developers increases the cognitive load for folks
using the platform. Enabling/disabling it on a per-installation level, and
- maybe - a per-space level, might be a decent compromise?
Agreed. I'd argue this this probably not be a 'per-app' thing, as I too
amy way of the knobs that developers like to turn. I think a per space
level is just the right level.
On Wed, Jul 29, 2015 at 10:20 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
That's still very much open for discussion. Obviously, someone with
administrative privileges should be in charge of this particular piece of
configuration.
Also making this a runtime config (e.g. feature flag) as opposed to a
deploy-time config (e.g. part of the CC config written out by BOSH) would
make the different behaviors more testable.
Thoughts? Preferences? We're wary of adding too many knobs to the
platform and exposing them all the way down to app developers increases the
cognitive load for folks using the platform. Enabling/disabling it on a
per-installation level, and - maybe - a per-space level, might be a decent
compromise?
Onsi
On Wed, Jul 29, 2015 at 9:54 AM, Matt Cowger <matt(a)cowger.us> wrote:
Once - configurable on a per-app, per space, or per deployment basis?
On Wed, Jul 29, 2015 at 9:50 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
Hey all,
Based on the feedback we got and the relatively low cost to maintain
privileged support we'd like to propose making running privileged
containers on the platform configurable - we will recommend this be turned
off when running untrusted workloads and it will likely default to off. We
have longer term plans to support mounting persistent volumes in Diego at
which point support for mounting FUSE in unprivileged containers can become
a reality.
Thoughts?
Onsi
On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:
On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <
vedran.lerenc(a)sap.com> wrote:
Hi Onsi,
Ø Thoughts? Concerns?
Well, that’s bad news.
We, and I assume many others as well (like the folks from Stackato
who do it in the public), have used SSHFS + FUSE to implement a persistent
file system for old-fashioned apps/apps that are not Cloud-native. I don’t
want to fight an ideological battle here, it’s just that these apps do
still exist (in majority) and a file system service is an important
service/feature for them.
So if you remove FUSE (which we thought is not going away/was added
to stay), it’s pretty bad for us/many apps.
Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very
helpful for running apps that depend on a persistent FS, like Wordpress.
Perhaps this use case of mounting a remote SSHFS could be supported in some
other way?
Dan
*From: *Onsi Fakhouri
*Reply-To: *"Discussions about Cloud Foundry projects and the
system overall."
*Date: *Saturday 11 July 2015 01:10
*To: *cf-dev
*Subject: *[cf-dev] Removing FUSE support from CF
Hey CF-Dev,
The Garden team has been hard at work substantially improving
Garden-Linux's security features. Garden-Linux now employs user namespaces
and drops capabilities when creating unprivileged containers - we're
excited to bring both of these features to the platform!
Diego currently runs applications in *privileged* containers.
These lack the security features outlined above and we are planning on
switching to launch all CF applications in *unprivileged*
containers.
Unfortunately, it has proved difficult to support
mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are
planning on removing support for FUSE in favor of better securing our
containers.* If/when FUSE support in unprivileged containers
becomes possible we may add it back to the platform.
Thoughts? Concerns?
Thanks!
Onsi
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Removing FUSE support from CF
Onsi Fakhouri <ofakhouri@...>
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 privileged containers isn't a step backwards. It's simply a choice not to take a step forwards.
Onsi
toggle quoted message
Show quoted text
On Jul 30, 2015, at 9:34 AM, Julian Friedman <julz.friedman(a)gmail.com> wrote:
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 a buildpack image this is less essential, but it means /even if/ a root escalation exploit is found (these do exist, there was an escalation via overlayfs patched a while ago) you're still safe. 'Privileged: false' turns on user namespacing and turns off various capabilities: it's what the Garden team recommend most containers use. 'Privileged: true' relies on the security of your rootfs and users never getting root; if your use case requires it you'll of course need to make a judgement, but you're trading off quite a lot of security in my opinion.
Sent from my iPhone
On 30 Jul 2015, at 17:12, Guillaume Berche <bercheg(a)gmail.com> wrote:
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 user namespace), when pushing an app that goes through the buildpack staging process (hence running as vcap user) ?
From http://godoc.org/github.com/cloudfoundry-incubator/garden I see
// If Privileged is true the container does not have a user namespace and the root user in the container
// is the same as the root user in the host. Otherwise, the container has a user namespace and the root
// user in the container is mapped to a non-root user in the host. Defaults to false.
Privileged bool `json:"privileged,omitempty"`
I understand the risk is specific to running a docker image built using the docker file USER directive (specially root): then the container will run as the host root ?
BTW, is the ability to run as a different user in staging and running currently considered as discussed into https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/ZlC-2DVOSHo/uRrF6Io52mEJ ?
Thanks,
Guillaume.
On Thu, Jul 30, 2015 at 3:27 AM, Jack Cai <greensight(a)gmail.com> wrote:
+1 for space-level configuration.
Jack
On Wed, Jul 29, 2015 at 2:04 PM, Matt Cowger <matt(a)cowger.us> wrote:
We're wary of adding too many knobs to the platform and exposing them all the way down to app developers increases the cognitive load for folks using the platform. Enabling/disabling it on a per-installation level, and - maybe - a per-space level, might be a decent compromise? Agreed. I'd argue this this probably not be a 'per-app' thing, as I too amy way of the knobs that developers like to turn. I think a per space level is just the right level.
On Wed, Jul 29, 2015 at 10:20 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io> wrote:
That's still very much open for discussion. Obviously, someone with administrative privileges should be in charge of this particular piece of configuration.
Also making this a runtime config (e.g. feature flag) as opposed to a deploy-time config (e.g. part of the CC config written out by BOSH) would make the different behaviors more testable.
Thoughts? Preferences? We're wary of adding too many knobs to the platform and exposing them all the way down to app developers increases the cognitive load for folks using the platform. Enabling/disabling it on a per-installation level, and - maybe - a per-space level, might be a decent compromise?
Onsi
On Wed, Jul 29, 2015 at 9:54 AM, Matt Cowger <matt(a)cowger.us> wrote:
Once - configurable on a per-app, per space, or per deployment basis?
On Wed, Jul 29, 2015 at 9:50 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io> wrote:
Hey all,
Based on the feedback we got and the relatively low cost to maintain privileged support we'd like to propose making running privileged containers on the platform configurable - we will recommend this be turned off when running untrusted workloads and it will likely default to off. We have longer term plans to support mounting persistent volumes in Diego at which point support for mounting FUSE in unprivileged containers can become a reality.
Thoughts?
Onsi
On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <vedran.lerenc(a)sap.com> wrote:
Hi Onsi,
Ø Thoughts? Concerns?
Well, that’s bad news.
We, and I assume many others as well (like the folks from Stackato who do it in the public), have used SSHFS + FUSE to implement a persistent file system for old-fashioned apps/apps that are not Cloud-native. I don’t want to fight an ideological battle here, it’s just that these apps do still exist (in majority) and a file system service is an important service/feature for them.
So if you remove FUSE (which we thought is not going away/was added to stay), it’s pretty bad for us/many apps.
Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very helpful for running apps that depend on a persistent FS, like Wordpress. Perhaps this use case of mounting a remote SSHFS could be supported in some other way?
Dan
From: Onsi Fakhouri
Reply-To: "Discussions about Cloud Foundry projects and the system overall."
Date: Saturday 11 July 2015 01:10
To: cf-dev
Subject: [cf-dev] Removing FUSE support from CF
Hey CF-Dev,
The Garden team has been hard at work substantially improving Garden-Linux's security features. Garden-Linux now employs user namespaces and drops capabilities when creating unprivileged containers - we're excited to bring both of these features to the platform!
Diego currently runs applications in privileged containers. These lack the security features outlined above and we are planning on switching to launch all CF applications in unprivileged containers.
Unfortunately, it has proved difficult to support mounting FUSE filesystems from within unprivileged containers. We believe the security benefits outweigh the features that FUSE give us and are planning on removing support for FUSE in favor of better securing our containers. If/when FUSE support in unprivileged containers becomes possible we may add it back to the platform.
Thoughts? Concerns?
Thanks!
Onsi
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev _______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev _______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Removing FUSE support from CF
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 a buildpack image this is less essential, but it means /even if/ a root escalation exploit is found (these do exist, there was an escalation via overlayfs patched a while ago) you're still safe. 'Privileged: false' turns on user namespacing and turns off various capabilities: it's what the Garden team recommend most containers use. 'Privileged: true' relies on the security of your rootfs and users never getting root; if your use case requires it you'll of course need to make a judgement, but you're trading off quite a lot of security in my opinion.
Sent from my iPhone
toggle quoted message
Show quoted text
On 30 Jul 2015, at 17:12, Guillaume Berche <bercheg(a)gmail.com> wrote:
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 user namespace), when pushing an app that goes through the buildpack staging process (hence running as vcap user) ?
From http://godoc.org/github.com/cloudfoundry-incubator/garden I see
// If Privileged is true the container does not have a user namespace and the root user in the container
// is the same as the root user in the host. Otherwise, the container has a user namespace and the root
// user in the container is mapped to a non-root user in the host. Defaults to false.
Privileged bool `json:"privileged,omitempty"`
I understand the risk is specific to running a docker image built using the docker file USER directive (specially root): then the container will run as the host root ?
BTW, is the ability to run as a different user in staging and running currently considered as discussed into https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/ZlC-2DVOSHo/uRrF6Io52mEJ ?
Thanks,
Guillaume.
On Thu, Jul 30, 2015 at 3:27 AM, Jack Cai <greensight(a)gmail.com> wrote:
+1 for space-level configuration.
Jack
On Wed, Jul 29, 2015 at 2:04 PM, Matt Cowger <matt(a)cowger.us> wrote:
We're wary of adding too many knobs to the platform and exposing them all the way down to app developers increases the cognitive load for folks using the platform. Enabling/disabling it on a per-installation level, and - maybe - a per-space level, might be a decent compromise? Agreed. I'd argue this this probably not be a 'per-app' thing, as I too amy way of the knobs that developers like to turn. I think a per space level is just the right level.
On Wed, Jul 29, 2015 at 10:20 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io> wrote:
That's still very much open for discussion. Obviously, someone with administrative privileges should be in charge of this particular piece of configuration.
Also making this a runtime config (e.g. feature flag) as opposed to a deploy-time config (e.g. part of the CC config written out by BOSH) would make the different behaviors more testable.
Thoughts? Preferences? We're wary of adding too many knobs to the platform and exposing them all the way down to app developers increases the cognitive load for folks using the platform. Enabling/disabling it on a per-installation level, and - maybe - a per-space level, might be a decent compromise?
Onsi
On Wed, Jul 29, 2015 at 9:54 AM, Matt Cowger <matt(a)cowger.us> wrote:
Once - configurable on a per-app, per space, or per deployment basis?
On Wed, Jul 29, 2015 at 9:50 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io> wrote:
Hey all,
Based on the feedback we got and the relatively low cost to maintain privileged support we'd like to propose making running privileged containers on the platform configurable - we will recommend this be turned off when running untrusted workloads and it will likely default to off. We have longer term plans to support mounting persistent volumes in Diego at which point support for mounting FUSE in unprivileged containers can become a reality.
Thoughts?
Onsi
On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <vedran.lerenc(a)sap.com> wrote:
Hi Onsi,
Ø Thoughts? Concerns?
Well, that’s bad news.
We, and I assume many others as well (like the folks from Stackato who do it in the public), have used SSHFS + FUSE to implement a persistent file system for old-fashioned apps/apps that are not Cloud-native. I don’t want to fight an ideological battle here, it’s just that these apps do still exist (in majority) and a file system service is an important service/feature for them.
So if you remove FUSE (which we thought is not going away/was added to stay), it’s pretty bad for us/many apps.
Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very helpful for running apps that depend on a persistent FS, like Wordpress. Perhaps this use case of mounting a remote SSHFS could be supported in some other way?
Dan
From: Onsi Fakhouri
Reply-To: "Discussions about Cloud Foundry projects and the system overall."
Date: Saturday 11 July 2015 01:10
To: cf-dev
Subject: [cf-dev] Removing FUSE support from CF
Hey CF-Dev,
The Garden team has been hard at work substantially improving Garden-Linux's security features. Garden-Linux now employs user namespaces and drops capabilities when creating unprivileged containers - we're excited to bring both of these features to the platform!
Diego currently runs applications in privileged containers. These lack the security features outlined above and we are planning on switching to launch all CF applications in unprivileged containers.
Unfortunately, it has proved difficult to support mounting FUSE filesystems from within unprivileged containers. We believe the security benefits outweigh the features that FUSE give us and are planning on removing support for FUSE in favor of better securing our containers. If/when FUSE support in unprivileged containers becomes possible we may add it back to the platform.
Thoughts? Concerns?
Thanks!
Onsi
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev _______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Is Garden limiting disk IOs ?
Will Pragnell <wpragnell@...>
Hi Guillaume,
No, Garden-Linux does not currently do any disk IO limiting.
Thanks,
Will
toggle quoted message
Show quoted text
|
|
|
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 changes in 3.1.1, please take a look at the commit log < https://github.com/cloudfoundry/java-buildpack/compare/v3.1...v3.1.1>. Packaged versions of the buildpack, suitable for use with create-buildpack and update-buildpack, can be found attached to this release < https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.1.1>. *Packaged Dependencies* - AppDynamics Agent: 4.0.7_0 - GemFire 8.0.0 - GemFire Modules 8.0.0.1 - GemFire Modules Tomcat7 8.0.0.1 - GemFire Security 8.0.0 - Groovy: 2.4.4 - JRebel 6.2.2 - MariaDB JDBC: 1.1.9 - Memory Calculator (centos6): 1.1.1.RELEASE - Memory Calculator (lucid): 1.1.1.RELEASE - Memory Calculator (mountainlion): 1.1.1.RELEASE - Memory Calculator (precise): 1.1.1.RELEASE - Memory Calculator (trusty): 1.1.1.RELEASE - New Relic Agent: 3.18.0 - OpenJDK JRE (centos6): 1.8.0_51 - OpenJDK JRE (lucid): 1.8.0_51 - OpenJDK JRE (mountainlion): 1.8.0_51 - OpenJDK JRE (precise): 1.8.0_51 - OpenJDK JRE (trusty): 1.8.0_51 - Play Framework JPA Plugin: 1.7.0.RELEASE - PostgreSQL JDBC: 9.4.1201 - RedisStore: 1.2.0_RELEASE - Spring Auto-reconfiguration: 1.7.0_RELEASE - Spring Boot CLI: 1.2.5_RELEASE - Tomcat Access Logging Support: 2.4.0_RELEASE - Tomcat Lifecycle Support: 2.4.0_RELEASE - Tomcat Logging Support: 2.4.0_RELEASE - Tomcat: 8.0.24 Christopher Frost - Pivotal UK Java Buildpack Team
|
|
|
Is Garden limiting disk IOs ?
Guillaume Berche
|
|
|
Re: Removing FUSE support from CF
Guillaume Berche
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 user namespace), when pushing an app that goes through the buildpack staging process (hence running as vcap user) ? From http://godoc.org/github.com/cloudfoundry-incubator/garden I see // If Privileged is true the container does not have a user namespace and the root user in the container // is the same as the root user in the host. Otherwise, the container has a user namespace and the root // user in the container is mapped to a non-root user in the host. Defaults to false. Privileged bool < http://godoc.org/builtin#bool> `json:"privileged,omitempty"` I understand the risk is specific to running a docker image built using the docker file USER directive (specially root): then the container will run as the host root ? BTW, is the ability to run as a different user in staging and running currently considered as discussed into https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/ZlC-2DVOSHo/uRrF6Io52mEJ? Thanks, Guillaume.
On Thu, Jul 30, 2015 at 3:27 AM, Jack Cai <greensight(a)gmail.com> wrote: +1 for space-level configuration.
Jack
On Wed, Jul 29, 2015 at 2:04 PM, Matt Cowger <matt(a)cowger.us> wrote:
We're wary of adding too many knobs to the platform and exposing them all the way down to app developers increases the cognitive load for folks
using the platform. Enabling/disabling it on a per-installation level, and
- maybe - a per-space level, might be a decent compromise?
Agreed. I'd argue this this probably not be a 'per-app' thing, as I too
amy way of the knobs that developers like to turn. I think a per space
level is just the right level.
On Wed, Jul 29, 2015 at 10:20 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
That's still very much open for discussion. Obviously, someone with
administrative privileges should be in charge of this particular piece of
configuration.
Also making this a runtime config (e.g. feature flag) as opposed to a
deploy-time config (e.g. part of the CC config written out by BOSH) would
make the different behaviors more testable.
Thoughts? Preferences? We're wary of adding too many knobs to the
platform and exposing them all the way down to app developers increases the
cognitive load for folks using the platform. Enabling/disabling it on a
per-installation level, and - maybe - a per-space level, might be a decent
compromise?
Onsi
On Wed, Jul 29, 2015 at 9:54 AM, Matt Cowger <matt(a)cowger.us> wrote:
Once - configurable on a per-app, per space, or per deployment basis?
On Wed, Jul 29, 2015 at 9:50 AM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:
Hey all,
Based on the feedback we got and the relatively low cost to maintain
privileged support we'd like to propose making running privileged
containers on the platform configurable - we will recommend this be turned
off when running untrusted workloads and it will likely default to off. We
have longer term plans to support mounting persistent volumes in Diego at
which point support for mounting FUSE in unprivileged containers can become
a reality.
Thoughts?
Onsi
On Mon, Jul 13, 2015 at 4:42 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:
On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <
vedran.lerenc(a)sap.com> wrote:
Hi Onsi,
Ø Thoughts? Concerns?
Well, that’s bad news.
We, and I assume many others as well (like the folks from Stackato
who do it in the public), have used SSHFS + FUSE to implement a persistent
file system for old-fashioned apps/apps that are not Cloud-native. I don’t
want to fight an ideological battle here, it’s just that these apps do
still exist (in majority) and a file system service is an important
service/feature for them.
So if you remove FUSE (which we thought is not going away/was added
to stay), it’s pretty bad for us/many apps.
Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very
helpful for running apps that depend on a persistent FS, like Wordpress.
Perhaps this use case of mounting a remote SSHFS could be supported in some
other way?
Dan
*From: *Onsi Fakhouri
*Reply-To: *"Discussions about Cloud Foundry projects and the
system overall."
*Date: *Saturday 11 July 2015 01:10
*To: *cf-dev
*Subject: *[cf-dev] Removing FUSE support from CF
Hey CF-Dev,
The Garden team has been hard at work substantially improving
Garden-Linux's security features. Garden-Linux now employs user namespaces
and drops capabilities when creating unprivileged containers - we're
excited to bring both of these features to the platform!
Diego currently runs applications in *privileged* containers.
These lack the security features outlined above and we are planning on
switching to launch all CF applications in *unprivileged*
containers.
Unfortunately, it has proved difficult to support
mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are
planning on removing support for FUSE in favor of better securing our
containers.* If/when FUSE support in unprivileged containers
becomes possible we may add it back to the platform.
Thoughts? Concerns?
Thanks!
Onsi
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
-- Matt
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: SSH access to CF app instances on Diego
Guillaume Berche
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 email and suggestion below for a way to quarantine the altered instances (beyond the per-space restart policy configuration). Such quarantine request might be a good place to include option to ask for the quarantine instances to be excluded from gorouter traffic. [1] http://www.activestate.com/blog/2015/07/cloud-foundry-advisory-board-meeting-2015-julyRegards, Guillaume.
On Fri, Jul 3, 2015 at 3:56 PM, Guillaume Berche <bercheg(a)gmail.com> wrote: Hi,
please find my feedback to this thread
*short version:*
1- need preserve good CF experience with HTTP only (direct SSH flow is
still blocked and a pain in many organisations) => +1 to preserve "cf
files" or fine tune diego plug to have ssh over HTTP to work out of the box
2- default "recycle tainted containers by default" policy seems good to me
3- needs to be completed with more control of the recycling policy (UX
such as "quarantine" or GAE "lock/unlock" )
4- development use-cases need to be better supported (dev/prod parity) not
sure ssh/scp is the right path though
*long version:*
*1- cf files and ssh over HTTP*
As previously mentionned into [1], CF exposing apis over HTTP api made a
great job to be easily consummed through HTTP proxies that some companies
still use, making CF experience seemless to consumme public paas, or
private paas among corporate entities. It seems important to me to preserve
good CF experience with HTTP only.
If SSH interactive access, scp and port forwarding become the mainstream
solution to operate and troubleshoot apps (supporting "cf files",
replacement for the previous DEBUG and CONSOLE ports), it will be useful
for users behind such firewalls to be able to configure diego ssh plugin to
use HTTP/SOCKS proxies to reach public CF instances. As the diego ssh cli
plugin supports using the regular local host ssh binaries, this may
potentially be done by tweaking the .ssh config file to add flags
associated to host ssh.${domain} to go through proxies (possibly double
tunnels as described into [2]). However, for new users in such network
context, especially on windows operating system, the set up work before
using a CF public instance starts to add up?
*2- default "recycle tainted containers by default" seems good to me*
Given that apps deployed on CF comply to 12 factor apps, there instance
may be restarted at anytime (e.g. during a CF new release deployment or
stemcell upgrade). So the default policy "recycle tainted containers by
default" is not a surprise.
*3- need to be completed with more control of the recycling policy (UX
such as "quarantine" or GAE "lock/unlock" )*
There are some specific use-cases where the "recycle tainted containers by
default" policy would be problematic when running applications in
production:
An application instance is malfunctionning (e.g. hanging) and an
interactive debugging is necessary. The app-ops ssh into the container and
starts taking some diagnostic steps (e.g sending kill -SIGTERM signals to
take thread dumps, or locally changes log levels).
If ever the ssh connection breaks/timeout, the "recycle tainted containers
by default, preventing the current diagnostc to complete.
Another similar use case: a production application is suspected to be
compromised by an attacker. App-ops need to capture evidences and
understand better how the abuse was done. There isn't enough information in
streamed logs, and there is a need to get into the container to inspect the
ephemeral FS and the processes and memory. This may require more than one
simultanenous SSH connection, and may span on multiple hours
In both use-cases above, while the application is 12 factor compliant and
the "recycle tainted containers by default" policy would be opted in on the
corresponding space, there would be a need to transiently turn the mode off.
In term of user experience, this may appear as an explicit user request to
"quarantine" the tainted app instances (or the whoe app) so that CF does
not attempt to restart them. Or it may appear as the google app engine
"lock/unlock"
a call to a new "unlock" command to a CF app instance would be necessary
to get SSH access to it. CF then considers this instance as
"tained"/untrusted, as it may have deviated from the pushed content, and
does not act to it anymore (i.e. does not monitor its bound $PORT or root
process exit, which may be handy to diagnose it as wish). When the "lock"
command is requested on this instance, Cf destroys this tainted instance,
and recreates a fresh new "trusted" one.
*4- development use-cases need to be better supported (dev/prod parity)
not sure ssh/scp is the right path though*
I agree with James Myers that development use-cases should be better
supported.
First, CF should strive to support dev-prod parity [4]. However currently,
there is not anymore a version of CF that a developper can run on his
laptop (e.g. when doing offline development during commute) that would
behave like prod and embed buildpacks. There used to have "CF on a single
VM". Heroku or GAE have emulators. Cloud rocker [5] is close, but it still
takes 10s or more to have changes made on the app be reflected into a
running app.
There are some legitimate use cases during development for modifying
sources of the application and have those changes be taken in effect
immediately. Lots of app development framework supports those development
modes (even those that promote test-driven practices), and getting a fast
feedback is important. Having dev-prod parity means supporting these use
cases while preserving prod behavior (having the VCAP_SERVICES and
VCAP_APPLICATION and the buildpack processing applied on the same stack
(cflinux2)). Being able to run offline would be even better.
I however believe that providing SSH/SCP access to change the file system
to a running app instance may not be the appropriate response, given the FS
and the app instance is still ephemeral. Who would want to modify files
that could be lost at any time (e.g. a stemcell upgrade ) ?
I'd rather see value in further exploring the ideas layed out by James
Bayer into [5] e.g. as a form of a git repo populated with the
/home/vcap/app subdir, that developers could clone, push to, and have the
instance epheremal FS updated with pushed changes.
This may be combined with a cloudrocker mechanism as to work with a fully
offline mode when this is required.
[1]
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/OavSBIhU_xQ/wJrT08iHfJ8J
[2] http://proxytunnel.sourceforge.net/paper.php
[3]
https://cloud.google.com/appengine/docs/managed-vms/host-env#changing_management
[4] http://12factor.net/dev-prod-parity
[5]
https://docs.google.com/document/d/1_C3OWS6giWx4JL_IL9YLA6jcppyQLVD-YjR0GeA8Z0s/edit#heading=h.toypuu5pxh65
On Thu, Jul 2, 2015 at 10:18 PM, James Myers <jmyers(a)pivotal.io> wrote:
I have to agree with Matt on this one. I feel that the recycling of
containers is a very anti-developer default. When you approach Cloud
Foundry from the perspective of running production applications the recycle
policy makes complete sense. However, I feel that this misses out on one of
the massive benefits/use cases of Cloud Foundry, what it offers to the
development process.
From a security stand point, if you can ssh into a container, it means
you have write access to the application in CloudFoundry. Thus you can
already push new bits/change the application in question. All of the
"papertrail" functionality around pushing/changing applications exists for
SSH as well (we record events, output log lines, make it visible to users
that action was taken on the application), and thus concerned operators
would be able to determine if someone modifying the application in question.
Therefore I'm lost on how this is truly the most secure default. If we
are really going by the idea that all defaults should be the most secure,
ssh should be disabled by default.
As a developer, I can see many times in which I would want to be able to
ssh into my container and change my application as part of a
troubleshooting process. Using BOSH as an example, CF Devs constantly ssh
into VMs and change the processes running on them in order to facilitate
development. BOSH does not reap the VM and redeploy a new instance when you
have closed the SSH session. Once again this is largely due to the fact
that if you have SSH access, you can already perform the necessary actions
to change the application through different means.
Another huge hindrance to development, is that the recycling policy is
controlled by administrators. It is not something that normal users can
control, even though we allow the granularity of enabling/disabling SSH
completely to the end user. This seems counterintuitive.
I feel that a better solution would be to provide the user with some
knowledge of which instances may be tainted, and then allowing them to opt
into a policy which will reap tainted containers. This provides users with
clear insight that their application instance may be a snowflake (and that
they may want to take action), while also allowing normal behavior with
regards to SSH access to containers.
To summarize, by enabling the recycling policy by default we not only
produce extremely unusual behavior / workflows for developers, we are also
minimizing the developer-friendliness of CF in general. This mixed with the
fact that as a user I cannot even control this policy, leads me to believe
that as a default recycling should be turned off as it provides the most
cohesive and friendly user experience.
On Mon, Jun 29, 2015 at 9:14 AM, John Wong <gokoproject(a)gmail.com> wrote:
after executing a command, concluding an interactive session, or copying a file into an instance, that instance will be restarted.
How does it monitor the behavior? Is there a list of commands
whitelisted? I am curious because I am trying to find out what the
whitelist contain. Also is it at the end of the bosh ssh APP_NAME session?
What if two users are there simultaneously?
Thanks.
On Mon, Jun 29, 2015 at 5:49 AM, Dieu Cao <dcao(a)pivotal.io> wrote:
I think with the CLI we could add clarifying messaging when using ssh
what the current policy around recycling is.
Eric, what do you think about calling it the "recycling" policy,
enabled by default? =D
-Dieu
On Sat, Jun 27, 2015 at 3:42 AM, Matthew Sykes <matthew.sykes(a)gmail.com
wrote: Depends on your role and where your app is in the deployment pipeline.
Most of the scenarios I envisioned were for the tail end of development
where you need to poke around to debug and figure out those last few
problems.
For example, Ryan Morgan was saying that the Cloud Foundry plugin for
eclipse is going to be using the ssh support in diego to enable debug of
application instances in the context of a buildpack deployed app. This is
aligned with other requirements I've heard from people working on dev tools.
As apps reach production, I would hope that interactive ssh is
disabled entirely on the prod space leaving only scp in source mode as an
option (something the proxy can do).
Between dev and prod, there's a spectrum, but in general, I either
expect access to be enabled or disabled - not enabled with a suicidal
tendency.
On Thu, Jun 25, 2015 at 10:53 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:
matt,
could you elaborate a bit on what you believe ssh access to instances
is for?
b
On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <
matthew.sykes(a)gmail.com> wrote:
My concern is the default behavior.
When I first prototyped this support in February, I never expected
that merely accessing a container would cause it to be terminated. As we
can see from Jan's response, it's completely unexpected; many others have
the same reaction.
I do not believe that this behavior should be part of the default
configuration and I do believe the control needs to be at the space level.
I have have already expressed this opinion during Diego retros and at the
runtime PMC meeting.
I honestly believe that if we were talking about applying this
behavior to `bosh ssh` and `bosh scp`, few would even consider running in a
'kill on taint mode' because of how useful it is. We should learn from that.
If this behavior becomes the default, I think our platform will be
seen as moving from opinionated to parochial. That would be unfortunate.
On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io>
wrote:
you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.
On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com>
wrote:
On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io>
wrote:
after executing a command, concluding an
interactive session, or copying a file into an instance, that instance will
be restarted. What is the purpose of being able to copy a file into an instance
if
the instance is restarted as soon as the file has been received?
Cheers,
-Jan
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Matthew Sykes
matthew.sykes(a)gmail.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Matthew Sykes
matthew.sykes(a)gmail.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Utilities PMC - 2015-07-07 notes
Guillaume Berche
toggle quoted message
Show quoted text
On Thu, Jul 30, 2015 at 3:06 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote: 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 specific to Pivotal, so I apologize for attempting to link
to it.
On Thu, Jul 9, 2015 at 1:05 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:
Thanks Mike for the detailed notes.
It seems the toolsmiths-tracker url is wrong and pointing to the
buildpacks tracker, and the IF-tracker has not yet been configured for
being public (I get an "You are not allowed to view the requested page.")
[toolsmiths-tracker]: https://www.pivotaltracker.com/n/projects/1042066
[lf-tracker]: https://www.pivotaltracker.com/n/projects/939266
Thanks in advance,
Guillaume.
On Wed, Jul 8, 2015 at 4:58 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:
Hi all,
We had a meeting of the Utilities PMC yesterday, permanent notes are at:
https://github.com/cloudfoundry/pmc-notes/blob/master/Utilities/2015-07-07-utilities.md
which I've helpfully copied into this email below.
Cheers,
-mike
-----
*# Utilities PMC Meeting 2015-07-07*
*## Agenda*
1. Update on CI tools (Mike Dalessio)
2. Update on CLI (Greg Oehmen)
3. Update on Eclipse plugin and Java tools (Ryan Morgan)
4. Proposal to accept receptor-client into incubation
5. Open Discussion
*## Attendees*
* Chip Childers, Cloud Foundry Foundation
* Mike Dalessio, Pivotal (PMC lead)
* Deepak Vij, Huawei
*## Update on CI tools (Mike Dalessio)*
- Krafa track of work has been broadly defined, and it's in the
Toolsmiths [public backlog and icebox][toolsmiths-tracker].
- A pair is continuing work on [License Finder][lf], which is an OSS
tool to
examine a project's declared dependencies (via a package manager)
and discover licenses and changes in licensing. This should be
useful for the Foundation as well. (See [Tracker here][lf-tracker].)
*## Update on CLI (Greg Oehman)*
The CLI team released version 6.12.1 on 7/6/2015. Release notes,
download instructions and binaries are available at
https://github.com/cloudfoundry/cli/releases
*## Update on Eclipse plugin and Java tools (Ryan Morgan)*
* Eclipse tooling 1.8.3 release (Nieraj posted notes about this to
cf-dev).
*## Proposal to accept receptor-client into incubation*
Last meeting, Ryan Morgan [proposed receptor-client for
acceptance][receptor-client-proposal] into incubation.
No objections having been raised, on either the mailing list or in the
PMC meeting, this is now accepted into incubation.
*## Open Discussion*
None.
-----
Links:
[toolsmiths-tracker]:
https://www.pivotaltracker.com/n/projects/1042066
[lf-tracker]: https://www.pivotaltracker.com/n/projects/939266
[lf]: https://github.com/pivotal/LicenseFinder
[receptor-client-proposal]:
http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-for-incubation-of-receptor-client-Java-client-for-receptor-td440.html
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: FYI: CAB call for July 2015 - moved to 7/15 @ 8a PDT
Guillaume Berche
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-julyThe MEGA section says the following: *Updates from this MEGA team for the past week include having extracted etcd-release and now they are working on extracting consul-release, setting up pipelines for them, testing them and publishing them to bosh.io < http://bosh.io/>.* *Longer-term they want to generalize the patterns that have been introduced for Diego around manifest generation.* *Cornelia Davis from Pivotal asked Amit to confirm whether manifest generation was moving away from Spiff, to which Amit replied "yes"."* Looking at diego repo, I still see the spiff installation instructions, and spiff used for manifest generation [2]. Where can I learn about the manifest generation pattern for diego, to better understand this CAB discussion ? Thanks in advance, Guillaume. [2] https://github.com/cloudfoundry-incubator/diego-release/blob/develop/scripts/generate-deployment-manifest#L84-L103On Tue, Jul 14, 2015 at 4:56 PM, Michael Maximilien <maxim(a)us.ibm.com> wrote: FYI...
Final reminder of the CAB call tomorrow at 8a PDT. See all info from last
week's email below.
Also reminder to all PMs to include their highlights and to others to list
any proposals or discussion items.
Talk to you all tomorrow morning. Best,
dr.max
ibm cloud labs
silicon valley, ca
Sent from my iPhone
On Jul 7, 2015, at 9:54 AM, Michael Maximilien <maxim(a)us.ibm.com> wrote:
Hi, all,
After conferring with James and Chip, we've agreed to move the call to
next week Wednesday @ same time (8a PDT).
This helps folks who have extended their July 4th holiday in U.S. and
hopefully is not inconvenient to others.
Finally, reminders:
1. Note the call information is relatively new (same as last time). Please
take note:
USA 888-426-6840; 215-861-6239 *| *Participant code: *1985291*
*Other countries: *http://goo.gl/RnNfc1
2. Please add to the agenda of you have something to discuss. I will send
reminders again early next week.
Agenda:
https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit
3. If you own any of the recurring meetings please update with above.
Thanks much. Best,
dr.max
ibm cloud labs
silicon valley, ca
dr.max
ibm cloud labs
silicon valley, ca
Sent from my iPhone
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Utilities PMC - 2015-07-07 notes
Sorry all, The correct URL for LicenseFinder tracker is: https://www.pivotaltracker.com/n/projects/234851However, the Toolsmiths tracker is private as there's quite a bit of work in there that's specific to Pivotal, so I apologize for attempting to link to it.
On Thu, Jul 9, 2015 at 1:05 AM, Guillaume Berche <bercheg(a)gmail.com> wrote: Thanks Mike for the detailed notes.
It seems the toolsmiths-tracker url is wrong and pointing to the
buildpacks tracker, and the IF-tracker has not yet been configured for
being public (I get an "You are not allowed to view the requested page.")
[toolsmiths-tracker]: https://www.pivotaltracker.com/n/projects/1042066
[lf-tracker]: https://www.pivotaltracker.com/n/projects/939266
Thanks in advance,
Guillaume.
On Wed, Jul 8, 2015 at 4:58 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:
Hi all,
We had a meeting of the Utilities PMC yesterday, permanent notes are at:
https://github.com/cloudfoundry/pmc-notes/blob/master/Utilities/2015-07-07-utilities.md
which I've helpfully copied into this email below.
Cheers,
-mike
-----
*# Utilities PMC Meeting 2015-07-07*
*## Agenda*
1. Update on CI tools (Mike Dalessio)
2. Update on CLI (Greg Oehmen)
3. Update on Eclipse plugin and Java tools (Ryan Morgan)
4. Proposal to accept receptor-client into incubation
5. Open Discussion
*## Attendees*
* Chip Childers, Cloud Foundry Foundation
* Mike Dalessio, Pivotal (PMC lead)
* Deepak Vij, Huawei
*## Update on CI tools (Mike Dalessio)*
- Krafa track of work has been broadly defined, and it's in the
Toolsmiths [public backlog and icebox][toolsmiths-tracker].
- A pair is continuing work on [License Finder][lf], which is an OSS tool
to
examine a project's declared dependencies (via a package manager)
and discover licenses and changes in licensing. This should be
useful for the Foundation as well. (See [Tracker here][lf-tracker].)
*## Update on CLI (Greg Oehman)*
The CLI team released version 6.12.1 on 7/6/2015. Release notes,
download instructions and binaries are available at
https://github.com/cloudfoundry/cli/releases
*## Update on Eclipse plugin and Java tools (Ryan Morgan)*
* Eclipse tooling 1.8.3 release (Nieraj posted notes about this to
cf-dev).
*## Proposal to accept receptor-client into incubation*
Last meeting, Ryan Morgan [proposed receptor-client for
acceptance][receptor-client-proposal] into incubation.
No objections having been raised, on either the mailing list or in the
PMC meeting, this is now accepted into incubation.
*## Open Discussion*
None.
-----
Links:
[toolsmiths-tracker]: https://www.pivotaltracker.com/n/projects/1042066
[lf-tracker]: https://www.pivotaltracker.com/n/projects/939266
[lf]: https://github.com/pivotal/LicenseFinder
[receptor-client-proposal]:
http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-for-incubation-of-receptor-client-Java-client-for-receptor-td440.html
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Utilities PMC - 2015-07-07 notes
Guillaume Berche
Mike, not sure you had seen my question to the utilities pointers below ?
toggle quoted message
Show quoted text
On Thu, Jul 9, 2015 at 7:05 AM, Guillaume Berche wrote: Thanks Mike for the detailed notes.
It seems the toolsmiths-tracker url is wrong and pointing to the
buildpacks tracker, and the IF-tracker has not yet been configured for
being public (I get an "You are not allowed to view the requested page.")
[toolsmiths-tracker]: https://www.pivotaltracker.com/n/projects/1042066
[lf-tracker]: https://www.pivotaltracker.com/n/projects/939266
Thanks in advance,
Guillaume.
On Wed, Jul 8, 2015 at 4:58 PM, Mike Dalessio wrote:
Hi all,
We had a meeting of the Utilities PMC yesterday, permanent notes are at:
https://github.com/cloudfoundry/pmc-notes/blob/master/Utilities/2015-07-07-utilities.md
which I've helpfully copied into this email below.
Cheers,
-mike
-----
*# Utilities PMC Meeting 2015-07-07*
*## Agenda*
1. Update on CI tools (Mike Dalessio)
2. Update on CLI (Greg Oehmen)
3. Update on Eclipse plugin and Java tools (Ryan Morgan)
4. Proposal to accept receptor-client into incubation
5. Open Discussion
*## Attendees*
* Chip Childers, Cloud Foundry Foundation
* Mike Dalessio, Pivotal (PMC lead)
* Deepak Vij, Huawei
*## Update on CI tools (Mike Dalessio)*
- Krafa track of work has been broadly defined, and it's in the
Toolsmiths [public backlog and icebox][toolsmiths-tracker].
- A pair is continuing work on [License Finder][lf], which is an OSS tool
to
examine a project's declared dependencies (via a package manager)
and discover licenses and changes in licensing. This should be
useful for the Foundation as well. (See [Tracker here][lf-tracker].)
*## Update on CLI (Greg Oehman)*
The CLI team released version 6.12.1 on 7/6/2015. Release notes,
download instructions and binaries are available at
https://github.com/cloudfoundry/cli/releases
*## Update on Eclipse plugin and Java tools (Ryan Morgan)*
* Eclipse tooling 1.8.3 release (Nieraj posted notes about this to
cf-dev).
*## Proposal to accept receptor-client into incubation*
Last meeting, Ryan Morgan [proposed receptor-client for
acceptance][receptor-client-proposal] into incubation.
No objections having been raised, on either the mailing list or in the
PMC meeting, this is now accepted into incubation.
*## Open Discussion*
None.
-----
Links:
[toolsmiths-tracker]: https://www.pivotaltracker.com/n/projects/1042066
[lf-tracker]: https://www.pivotaltracker.com/n/projects/939266
[lf]: https://github.com/pivotal/LicenseFinder
[receptor-client-proposal]:
http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-for-incubation-of-receptor-client-Java-client-for-receptor-td440.html
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Guillaume Berche
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 upon arrival of traffic on their routes. Similar to google app engine default behavior [1] I did not find mentions of this yet in mailing lists and trackers. We feel at Orange that such feature can improve the density for some of our non-prod use-cases (with environmental and financial benefits). I'd like to know if someone in the community already worked on such feature or would be interested in collaborating on an opensource implementation. I drafted some specs for a java-based implementation we're planning to work on [2]. I'd love to hear feedbacks and suggestions on this. Thanks in advance, Guillaume. [1] https://cloud.google.com/appengine/docs/java/modules/[2] https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#
|
|
|
Re: Soliciting feedback on a UX change for route services
Guillaume Berche
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 behavior you're suggesting (picking a different app instance) seems sensible to me, even though it will lead to seldom false associations. We can imagine to refine this behavior in a second step, when use-cases of router service being sensitive to false associations become more frequent: allow the gorouter to comply to hints provided by the route service to tune the behavior in case the pre-determined app might not exist anymore. The router service could for instance augment the router-service HTTP header with hints fields: - missing-app-policy with one of the following values: - reassign-app: the router transparently route the request to another app(default) - reject: reject the request (e.g. 502 status code with a json body providing the currently available app ids). In this case the route service may reemit the request to the gorouter, specifying the second param below - route-to-app override the predetermined app to which to route the traffic I'm currently planning to implement a route-service that would leverage the app_id in the request in an "autosleep", see [1]. The "reassign-app" default policy seems fine as a first step. The reject policy would be a nice refinement to close this corner case. [1] https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#Guillaume.
On Sat, Jul 18, 2015 at 12:08 AM, Shannon Coen <scoen(a)pivotal.io> wrote: Guillaume,
Including the app_id with the request forwarded to the route service
becomes misleading/false when, upon receiving the request back from the
route service, the pre-determined app no longer has instances available. At
that time GoRouter should be able to choose a different app instance for
the route, possibly of a different app, rather than rejecting the request
or re-forwarding the request to the route service with a different app id.
Otherwise, the route service may be making false associations.
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
On Thu, Jun 25, 2015 at 9:19 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:
I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering
cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s rate-limiting
Besides, If the MVP does not include support for multiple route services,
route service implementers might be able to experiment with supporting
arbitrary params as a way for users to specify fine grain options, possibly
ordered
cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'
+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")
Lastly, it seems important that route services be able to output logs
that end up being associated with the app that receive the associated
traffic (e.g. cache hit or cache miss for a specific incoming request).
With route services being associated to routes (and not being bound to app
instances anymore), I'd like to re-iterate the suggestion I made in the
design document (on Feb 17) to have the gorouter include the app_id in the
headers of the signed request it sends to route service(s). This will allow
for a route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).
Guillaume.
On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
This is great. Thank you, Mike.
FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.
cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:
This is interesting. Could you flesh this out for me? What use cases
do you have in mind for associating a service instance with a route, but
not providing a forwarding address?
I would imagine you could bind a service to a route any time you want
to customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.
Here are a few examples:
* A Public facing service as an indicator that a given route should be
made public facing. (Would require a broker to orchestrate stuff outside
of CF DNS, applying DoS security profiles to the route, force ssl on the
front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on
a route. Again could be implemented as a proxy if you trust
X-Forwarded-For or simply change some config on a front end load balancer
no new proxy needed.
Basically a service applied to a route could trigger and manage all
kinds of functionality not necessarily implemented as proxy orchestrated by
the GoRouter.
It also occurs to me that the only time chain ordering of route
services seems to be an issue is in the case of a proxy url. So, it is
unfortunate that I'd be limited to binding only one route service when I
may want to apply all kinds of functionality to a route not implemented as
a proxy because user defined ordering isn't an issue.
That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.
Mike
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: CF-Abacus: incubation and inception meeting coming soon
Alexander Lomov <alexander.lomov@...>
Hello, Maxim. I am Alexander Lomov. I work in R&D department at Altoros. I would like to participate in your Hangout meeting dedicated to CF Abacus. Could you please tell when and how I can participate. Thank you, Alex L. ------------------------ Alex Lomov *Altoros* — Cloud Foundry deployment, training and integration *Twitter:* @code1n < https://twitter.com/code1n> *GitHub:* @allomov < https://gist.github.com/allomov>
|
|
|
Questions about /v2/app_usage_events
王小锋 <zzuwxf at gmail.com...>
Hi, there
I noticed there are three state about the app event, started, stopped and
buildpack_set.
what does "buildpack_set" mean? If the app is in buildpack_set status, does
it occupy cup/memory/disk?
If the app is deleted, will the event reflected in app_usage_events? if no,
should I use /v2/app_usage_events together with
/v2/events?q=type:audit.app.delete-request to determine the lifetime of an
app?
Many thanks.
|
|
|
