/cc @dalanlan

Do they mount it in a way that /proc/self/cgroup's path field is correct?

I have, in the past, argued that this was an acceptable API. I'm less
confident now - back then I assumed people had LMCTFY to isolate themselves
from the vagaries of the kernel...

On Thu, Sep 10, 2015 at 5:31 PM, Dawn Chen notifications@github.com wrote:

Docker 1.8 now provides a container its own cgroups filesystem view
(read-only) by default. But there is no way to view host's cgroup
information to know the node resource usages. Once we really enforce QoS
and overcommit the node, this feature might be important for those
containers with Burstable class, so that the application itself could have
finer control on their resource consumption to avoid eviction due to system
Out-of-Resource condition.

There are many other ways to achieve this. I am just throwing this to kick
out the discussion.

cc/ @lvlv https://github.com/lvlv @thockin https://github.com/thockin
@bgrant0607 https://github.com/bgrant0607

—
Reply to this email directly or view it on GitHub
#13845.

@thockin: No. Docker mounts container cgroups at `/' within the container. I would prefer not exposing cgroups at all. One of the ideas discussed in #9473 was to make kubelet provide a read-only API which applications can use to get their resource limits.

LOL so I can't even use /proc/self/cgroup? Sigh...

Or did cgroup namespace get implemented in docker when I wasn't looking.

I prefer the idea of an API on a link-local IP

On Thu, Sep 10, 2015 at 10:41 PM, Vish Kannan notifications@github.com
wrote:

@thockin https://github.com/thockin: No. Docker mounts container
cgroups at `/' within the container. I would prefer not exposing cgroups at
all. One of the ideas discussed in #9473
#9473 was to make
kubelet provide a read-only API which applications can use to get their
resource limits.

—
Reply to this email directly or view it on GitHub
#13845 (comment)
.

Kubelet provides an read-only API on a link-local IP sounds good to me, and when @lvlv and I talked this at Hangzhou conference two weeks ago, we proposed the same solution on this.

But I do have some concerns on providing such API: Get container's resource limit is straightforward, but exposing various cgroup stats through read-only API will introduce new complexities to the kubelet itself. Also are we going to rate limit API per container / pod? through token? policy on throttling? Caching API calls? I guess since we are going to standardize Kubelet API anyway, all above should be take care anyway.

cgroup namespaces hasn't been completed yet.

On Thu, Sep 10, 2015 at 11:43 PM, Dawn Chen notifications@github.com
wrote:

Kubelet provides an read-only API on a link-local IP sounds good to me,
and when @lvlv https://github.com/lvlv and I talked this at Hangzhou
conference two weeks ago, we proposed the same solution on this.

But I do have some concerns on providing such API: Get container's
resource limit is straightforward, but exposing various cgroup stats
through read-only API will introduce new complexities to the kubelet
itself. Also are we going to rate limit API per container / pod? through
token? policy on throttling? Caching API calls? I guess since we are going
to standardize Kubelet API anyway, all above should be take care anyway.

—
Reply to this email directly or view it on GitHub
#13845 (comment)
.

Also discussed some in #386.

In addition to the comments above, we have to be careful about what we expose from the node.

@dchen1107 shall we close this issue?

On Mon, Sep 14, 2015 at 11:51 PM, Brian Grant notifications@github.com
wrote:

Also discussed some in #386
#386.

In addition to the comments above, we have to be careful about what we
expose from the node.

—
Reply to this email directly or view it on GitHub
#13845 (comment)
.

I'm still hungry for such an API, it will be a great gateway for user
containers to detect the environment it is running, for example, it could
help containers optimize the locality in IO.

In our test, given the identity of the host, Hive could improve its
performance greatly (3x because of short-circuit read/write) when it could
detect the DataNode at the same node.

On Wed, Sep 16, 2015 at 12:12 AM, Vish Kannan notifications@github.com
wrote:

@dchen1107 shall we close this issue?

On Mon, Sep 14, 2015 at 11:51 PM, Brian Grant notifications@github.com
wrote:

Also discussed some in #386
#386.

In addition to the comments above, we have to be careful about what we
expose from the node.

—
Reply to this email directly or view it on GitHub
<
#13845 (comment)

.

—
Reply to this email directly or view it on GitHub
#13845 (comment)
.

@lvlv: #9473 has a detailed discussion.

@vishh #9473 only talks about container itself's resource limit. For that, providing a readonly API is sufficient and based on the use pattern, it should be safe unless many bad users on a node queries its resource limits every short interval. This one is filed for a different use pattern, which on purpose to allow the user periodically query Kubelet since the usage changes quickly, thus, we need to think more about API call overhead here.

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Freeze the issue for 90d with /lifecycle frozen.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close