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.
> >
> > Teju
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
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
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
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
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 PM
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 t
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 h
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
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 wi
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
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 wrote:
> > Additionally, Tejun has specified that we do not want users to b
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 cgroup
Ooh, can you also please cc Li Zefan when
replying?
Thanks.
--
tejun
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
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 cg
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
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 wrote:
> Quoting Tim
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 b
lmctfy literally supports ".." as a container name :)
On Tue, Nov 26, 2013 at 12:58 PM, Serge E. Hallyn wrote:
> Quoting Tim Hockin (thoc...@google.com):
>> On Mon, Nov 25, 2013 at 9:47 PM, Serge E. Hallyn wrote:
>> > Quoting Tim Hockin (thoc...@google.com):
> ...
>> >> > . A client (requestor
Quoting Tim Hockin (thoc...@google.com):
> On Mon, Nov 25, 2013 at 9:47 PM, Serge E. Hallyn 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
> >> > r
On Tue, Nov 26, 2013 at 8:37 AM, Serge E. Hallyn 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 spec,
>
>
On Tue, Nov 26, 2013 at 8:12 AM, Serge E. Hallyn 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 expect to
On Mon, Nov 25, 2013 at 9:47 PM, Serge E. Hallyn 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 wrote:
>> > Additionally, Tejun has specified
On Tue, Nov 26, 2013 at 8:41 AM, Serge E. Hallyn wrote:
> Quoting Victor Marmol (vmar...@google.com):
> > On Tue, Nov 26, 2013 at 8:12 AM, Serge E. Hallyn
> wrote:
> >
> > > Quoting Tim Hockin (thoc...@google.com):
> > > > What are the requirements/goals around performance and concurrency?
> > >
Quoting Victor Marmol (vmar...@google.com):
> On Tue, Nov 26, 2013 at 8:12 AM, Serge E. Hallyn 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
>
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 http://www.freedesktop.org/wiki/Software/systemd/ControlGroup
On Tue, Nov 26, 2013 at 8:12 AM, Serge E. Hallyn 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 expec
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 d
Le lundi 25 novembre 2013 à 20:52 -0800, Tim Hockin a écrit :
> 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
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 wrote:
> Additionally, Tejun has specified that we do not want users to be
> too closely tied to the cgroupfs implementation. Therefore
> commands will be
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
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 wrote:
> > Additionally, Tejun has specified that we do not want users to be
> > too closely tied to the cg
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 practi
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 des
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
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
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
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 ins
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; t
39 matches
Mail list logo
