Hello, Tim.
On Tue, Dec 03, 2013 at 08:53:21PM -0800, Tim Hockin wrote:
If this daemon works as advertised, we will explore moving all write
traffic to use it. I still have concerns that this can't handle read
traffic at the scale we need.
At least from the kernel side, cgroup doesn't and
Quoting Tim Hockin (thoc...@google.com):
If this daemon works as advertised, we will explore moving all write
traffic to use it. I still have concerns that this can't handle read
traffic at the scale we need.
Tejun, I am not sure why chown came back into the conversation. This
is a
Quoting Victor Marmol (vmar...@google.com):
I thought we were going to use chown in the initial version to enforce the
ownership/permissions on the hierarchy. Only the cgroup manager has access
to the hierarchy, but it tries to access the hierarchy as the user that
sent the request. It was
On Wed, Dec 04, 2013 at 09:54:37AM -0600, Serge Hallyn wrote:
Quoting Tim Hockin (thoc...@google.com):
If this daemon works as advertised, we will explore moving all write
traffic to use it. I still have concerns that this can't handle read
traffic at the scale we need.
Tejun, I am
Hello, guys.
Sorry about the delay.
On Mon, Nov 25, 2013 at 10:43:35PM +, Serge E. Hallyn wrote:
Additionally, Tejun has specified that we do not want users to be
too closely tied to the cgroupfs implementation. Therefore
commands will be just a hair more general than specifying cgroupfs
Ooh, can you also please cc Li Zefan lize...@huawei.com when
replying?
Thanks.
--
tejun
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how
Hello, Tim.
On Mon, Nov 25, 2013 at 08:58:09PM -0800, Tim Hockin wrote:
Thanks for this! I think it helps a lot to discuss now, rather than
over nearly-done code.
On Mon, Nov 25, 2013 at 2:43 PM, Serge E. Hallyn se...@hallyn.com wrote:
Additionally, Tejun has specified that we do not want
Hello,
On Tue, Nov 26, 2013 at 09:19:18AM -0800, Victor Marmol wrote:
From my discussions with Tejun, he wanted to move to using inotify so it
may still be an fd we pass around.
Hm, would that just be inotify on the memory.max_usage_in_bytes
file, of inotify on a specific fd you've
Quoting Tejun Heo (t...@kernel.org):
Hello, guys.
Sorry about the delay.
On Mon, Nov 25, 2013 at 10:43:35PM +, Serge E. Hallyn wrote:
Additionally, Tejun has specified that we do not want users to be
too closely tied to the cgroupfs implementation. Therefore
commands will be just
Hello, Serge.
On Tue, Dec 03, 2013 at 06:03:44PM -0600, Serge Hallyn wrote:
As I communicated multiple times before, delegating write access to
control knobs to untrusted domain has always been a security risk and
is likely to continue to remain so. Also, organizationally, a
Then that
And can somebody please fix up lxc-devel so that it doesn't generate
your message awaits moderator approval notification on *each*
message? :(
--
tejun
--
Sponsored by Intel(R) XDK
Develop, test and display web and
Quoting Tejun Heo (t...@kernel.org):
Hello, Serge.
On Tue, Dec 03, 2013 at 06:03:44PM -0600, Serge Hallyn wrote:
As I communicated multiple times before, delegating write access to
control knobs to untrusted domain has always been a security risk and
is likely to continue to remain
If this daemon works as advertised, we will explore moving all write
traffic to use it. I still have concerns that this can't handle read
traffic at the scale we need.
Tejun, I am not sure why chown came back into the conversation. This
is a replacement for that.
On Tue, Dec 3, 2013 at 6:31
I thought we were going to use chown in the initial version to enforce the
ownership/permissions on the hierarchy. Only the cgroup manager has access
to the hierarchy, but it tries to access the hierarchy as the user that
sent the request. It was only meant to be a for now solution while the
real
At the start of this discussion, some months ago, we offered to
co-devel this with Lennart et al. They did not seem keen on the idea.
If they have an established DBUS protocol spec, we should consider
adopting it instead of a new one, but we CAN'T just play follow the
leader and do whatever they
Thanks for this! I think it helps a lot to discuss now, rather than
over nearly-done code.
On Mon, Nov 25, 2013 at 2:43 PM, Serge E. Hallyn se...@hallyn.com wrote:
Additionally, Tejun has specified that we do not want users to be
too closely tied to the cgroupfs implementation. Therefore
Quoting Tim Hockin (thoc...@google.com):
What are the requirements/goals around performance and concurrency?
Do you expect this to be a single-threaded thing, or can we handle
some number of concurrent operations? Do you expect to use threads of
processes?
The cgmanager should be pretty
On Tue, Nov 26, 2013 at 8:12 AM, Serge E. Hallyn se...@hallyn.com wrote:
Quoting Tim Hockin (thoc...@google.com):
What are the requirements/goals around performance and concurrency?
Do you expect this to be a single-threaded thing, or can we handle
some number of concurrent operations? Do
Quoting Tim Hockin (thoc...@google.com):
At the start of this discussion, some months ago, we offered to
co-devel this with Lennart et al. They did not seem keen on the idea.
If they have an established DBUS protocol spec,
see
On Tue, Nov 26, 2013 at 8:41 AM, Serge E. Hallyn se...@hallyn.com wrote:
Quoting Victor Marmol (vmar...@google.com):
On Tue, Nov 26, 2013 at 8:12 AM, Serge E. Hallyn se...@hallyn.com
wrote:
Quoting Tim Hockin (thoc...@google.com):
What are the requirements/goals around performance
On Mon, Nov 25, 2013 at 9:47 PM, Serge E. Hallyn se...@hallyn.com wrote:
Quoting Tim Hockin (thoc...@google.com):
Thanks for this! I think it helps a lot to discuss now, rather than
over nearly-done code.
On Mon, Nov 25, 2013 at 2:43 PM, Serge E. Hallyn se...@hallyn.com wrote:
On Tue, Nov 26, 2013 at 8:12 AM, Serge E. Hallyn se...@hallyn.com wrote:
Quoting Tim Hockin (thoc...@google.com):
What are the requirements/goals around performance and concurrency?
Do you expect this to be a single-threaded thing, or can we handle
some number of concurrent operations? Do you
On Tue, Nov 26, 2013 at 8:37 AM, Serge E. Hallyn se...@hallyn.com wrote:
Quoting Tim Hockin (thoc...@google.com):
At the start of this discussion, some months ago, we offered to
co-devel this with Lennart et al. They did not seem keen on the idea.
If they have an established DBUS protocol
Quoting Tim Hockin (thoc...@google.com):
On Mon, Nov 25, 2013 at 9:47 PM, Serge E. Hallyn se...@hallyn.com wrote:
Quoting Tim Hockin (thoc...@google.com):
...
. A client (requestor 'r') can make cgroup requests over
/sys/fs/cgroup/manager using dbus calls. Detailed privilege
lmctfy literally supports .. as a container name :)
On Tue, Nov 26, 2013 at 12:58 PM, Serge E. Hallyn se...@hallyn.com wrote:
Quoting Tim Hockin (thoc...@google.com):
On Mon, Nov 25, 2013 at 9:47 PM, Serge E. Hallyn se...@hallyn.com wrote:
Quoting Tim Hockin (thoc...@google.com):
...
.
Quoting Tim Hockin (thoc...@google.com):
lmctfy literally supports .. as a container name :)
So is ../.. ever used, or does noone every do anything beyond ..?
--
Rapidly troubleshoot problems before they affect your
I think most of our usecases have only wanted to know about the parent, but
I can see people wanting to go further. Would it be much different to
support both? I feel like it'll be simpler to support all if we go that
route.
On Tue, Nov 26, 2013 at 1:28 PM, Serge E. Hallyn se...@hallyn.com
I see three models:
1) Don't virtualize the cgroup path. This is what lmctfy does,
though we have discussed changing to:
2) Virtualize to an administrative root - I get to tell you where
your root is, and you can't see anythign higher than that.
3) Virtualize to CWD root - you can never go up,
I was planning on doing #3, but since you guys need to access .., my
plan is to have 'a/b' refer to $cwd/a/b while /a/b is the absolute
path, and allow read and eventfd but no write to any parent dirs.
Quoting Tim Hockin (thoc...@google.com):
I see three models:
1) Don't virtualize the cgroup
On 11/26/2013 12:43 AM, Serge E. Hallyn wrote:
Hi,
as i've mentioned several times, I want to write a standalone cgroup
management daemon. Basic requirements are that it be a standalone
program; that a single instance running on the host be usable from
containers nested at any depth; that
On Tue, Nov 26, 2013 at 02:03:16AM +0200, Marian Marinov wrote:
On 11/26/2013 12:43 AM, Serge E. Hallyn wrote:
Hi,
as i've mentioned several times, I want to write a standalone cgroup
management daemon. Basic requirements are that it be a standalone
program; that a single instance
On 11/26/2013 02:11 AM, Stéphane Graber wrote:
On Tue, Nov 26, 2013 at 02:03:16AM +0200, Marian Marinov wrote:
On 11/26/2013 12:43 AM, Serge E. Hallyn wrote:
Hi,
as i've mentioned several times, I want to write a standalone cgroup
management daemon. Basic requirements are that it be a
On Tue, Nov 26, 2013 at 03:35:22AM +0200, Marian Marinov wrote:
On 11/26/2013 02:11 AM, Stéphane Graber wrote:
On Tue, Nov 26, 2013 at 02:03:16AM +0200, Marian Marinov wrote:
On 11/26/2013 12:43 AM, Serge E. Hallyn wrote:
Hi,
as i've mentioned several times, I want to write a standalone
Serge...
You have no idea how much I dread mentioning this (well, after
LinuxPlumbers, maybe you can) but... You do realize that some of this
is EXACTLY what the systemd crowd was talking about there in NOLA back
then. I sat in those session grinding my teeth and listening to
comments from some
Haha,
I was wondering how long it'd take before we got the first comment about
systemd's own cgroup manager :)
To try and keep this short, there are a lot of cases where systemd's
plan of having an in-pid1 manager, as practical as it's for them, just
isn't going to work for us.
I believe our
On Mon, 2013-11-25 at 21:43 -0500, Stéphane Graber wrote:
Haha,
I was wondering how long it'd take before we got the first comment about
systemd's own cgroup manager :)
To try and keep this short, there are a lot of cases where systemd's
plan of having an in-pid1 manager, as practical as
Quoting Tim Hockin (thoc...@google.com):
Thanks for this! I think it helps a lot to discuss now, rather than
over nearly-done code.
On Mon, Nov 25, 2013 at 2:43 PM, Serge E. Hallyn se...@hallyn.com wrote:
Additionally, Tejun has specified that we do not want users to be
too closely tied
37 matches
Mail list logo
