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
On Tue, 26 Nov 2013 05:27:34 +0200
Marian Marinov m...@yuhu.biz wrote:
On 11/26/2013 04:58 AM, Stéphane Graber wrote:
On Tue, Nov 26, 2013 at 04:04:36AM +0200, Marian Marinov wrote:
I just read on LWN about the checkpoint/restore tool:
http://lwn.net/Articles/574917/
I think I
On Mon, Nov 25, 2013 at 02:34:40PM -0500, Michael H. Warfield wrote:
Introducing a new template (which is a modified template of a modified
template) for CentOS.
--
Added templates/lxc-centos for CentOS containers.
This adds an lxc-centos template for crreating CentOS 5+ templates. It
On Tue, 2013-11-26 at 10:45 -0500, Stéphane Graber wrote:
On Mon, Nov 25, 2013 at 02:34:40PM -0500, Michael H. Warfield wrote:
Introducing a new template (which is a modified template of a modified
template) for CentOS.
--
Added templates/lxc-centos for CentOS containers.
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, 2013-11-26 at 10:45 -0500, Stéphane Graber wrote:
On Mon, Nov 25, 2013 at 02:34:40PM -0500, Michael H. Warfield wrote:
Introducing a new template (which is a modified template of a modified
template) for CentOS.
--
Added templates/lxc-centos for CentOS containers.
On 11/26/2013 05:29 PM, Dwight Engen wrote:
On Mon, 25 Nov 2013 21:58:13 -0500
Stéphane Graber stgra...@ubuntu.com wrote:
On Tue, Nov 26, 2013 at 04:04:36AM +0200, Marian Marinov wrote:
Hey guys,
I just read on LWN about the checkpoint/restore tool:
http://lwn.net/Articles/574917/
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
Branch: refs/heads/master
Home: https://github.com/lxc/lxc
Commit: 164105f6563d98b832f603e28e506dbabed22cf3
https://github.com/lxc/lxc/commit/164105f6563d98b832f603e28e506dbabed22cf3
Author: Michael H. Warfield m...@wittsend.com
Date: 2013-11-26 (Tue, 26 Nov 2013)
Changed
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
This adds a new list_containers function to the python3 binding and a
matching override in __init__.py that adds the as_object parameter.
This should be compatible to the previous pure python implementation
with the advantage of also listing active non-defined containers (fixing
github issue
Quoting Stéphane Graber (stgra...@ubuntu.com):
This adds a new list_containers function to the python3 binding and a
matching override in __init__.py that adds the as_object parameter.
This should be compatible to the previous pure python implementation
with the advantage of also listing
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 2013/11/27 0:19, Marian Marinov wrote:
On my test setup it works for processes like apache, dovecot and mysql.
However it does not work with containers:
root@s321:~# criu dump -D deb1 -t 19332 --file-locks
(00.004962) Error (namespaces.c:155): Can't dump nested pid namespace for
Branch: refs/heads/master
Home: https://github.com/lxc/lxc
Commit: 44b97d6191fc31545b347be1c27b430bfe36de92
https://github.com/lxc/lxc/commit/44b97d6191fc31545b347be1c27b430bfe36de92
Author: Stéphane Graber stgra...@ubuntu.com
Date: 2013-11-26 (Tue, 26 Nov 2013)
Changed
25 matches
Mail list logo
