[lxc-devel] [nova-lxd/master] Update requirements

2016-02-10 Thread zulcss on Github 
The following pull request was submitted through Github.
It can be accessed and reviewed at: https://github.com/lxc/nova-lxd/pull/106

This e-mail was sent by the LXC bot, direct replies will not reach the author
unless they happen to be subscribed to this list.

=== Description (from pull-request) ===
Signed-off-by: Chuck Short 






  http://ogp.me/ns# fb: http://ogp.me/ns/fb# object: 
http://ogp.me/ns/object# article: http://ogp.me/ns/article# profile: 
http://ogp.me/ns/profile#;>


https://assets-cdn.github.com/assets/github-8a53a53d5feade5191874a5bbafa52ba0d8f6eeb48011f6b311788fdb747b804.css;
 media="all" rel="stylesheet" />
https://assets-cdn.github.com/assets/github2-e3a5b81e0737b90f1e6ff8e852b921f7ad8a4426c85776cf0b780295ffad25ac.css;
 media="all" rel="stylesheet" />




https://assets-cdn.github.com/assets/frameworks-ee521b8e9facac68ff27e93fc3ae0f8ed811d7bf9e434e84f4b9ea227780b084.js;
 rel="preload" />
https://assets-cdn.github.com/assets/github-863d0e4c2905010278cfd87e9c7c738e812530db73c36c274a185354977a2e41.js;
 rel="preload" />






Update requirements by zulcss · Pull Request #106 · lxc/nova-lxd · 
GitHub

https://github.com/fluidicon.png; 
title="GitHub">












  https://avatars1.githubusercontent.com/u/319235?v=3s=400; 
name="twitter:image:src" />
  https://avatars1.githubusercontent.com/u/319235?v=3s=400; 
property="og:image" />https://github.com/lxc/nova-lxd/pull/106; property="og:url" />
  https://api.github.com/_private/browser/stats;>
https://api.github.com/_private/browser/errors;>
https://assets-cdn.github.com/;>

















  







  

  https://assets-cdn.github.com/pinned-octocat.svg; color="#4078c0">
  https://assets-cdn.github.com/favicon.ico;>






  
  
span.labelstyle-fc2929, .linked-labelstyle-fc2929 {  background-color: 
#fc2929 !important;  color: #fff !important;}.labelstyle-fc2929.selected {  
background-color: #fc2929 !important;  color: #fff 
!important;}.label-select-menu .labelstyle-fc2929.selected {  
background:rgba(252, 41, 41, 0.12) !important;  color: #991818 !important;}

span.labelstyle-cc, .linked-labelstyle-cc {  background-color: #cc 
!important;  color: #33 !important;}.labelstyle-cc.selected {  
background-color: #cc !important;  color: #33 
!important;}.label-select-menu .labelstyle-cc.selected {  
background:rgba(204, 204, 204, 0.12) !important;  color: #99 !important;}

span.labelstyle-84b6eb, .linked-labelstyle-84b6eb {  background-color: #84b6eb 
!important;  color: #1c2733 !important;}.labelstyle-84b6eb.selected {  
background-color: #84b6eb !important;  color: #1c2733 
!important;}.label-select-menu .labelstyle-84b6eb.selected {  
background:rgba(132, 182, 235, 0.12) !important;  color: #557699 !important;}

span.labelstyle-159818, .linked-labelstyle-159818 {  background-color: #159818 
!important;  color: #fff !important;}.labelstyle-159818.selected {  
background-color: #159818 !important;  color: #fff 
!important;}.label-select-menu .labelstyle-159818.selected {  
background:rgba(21, 152, 24, 0.12) !important;  color: #159918 !important;}

span.labelstyle-e6e6e6, .linked-labelstyle-e6e6e6 {  background-color: #e6e6e6 
!important;  color: #33 !important;}.labelstyle-e6e6e6.selected {  
background-color: #e6e6e6 !important;  color: #33 
!important;}.label-select-menu .labelstyle-e6e6e6.selected {  
background:rgba(230, 230, 230, 0.12) !important;  color: #99 !important;}

span.labelstyle-cc317c, .linked-labelstyle-cc317c {  background-color: #cc317c 
!important;  color: #fff !important;}.labelstyle-cc317c.selected {  
background-color: #cc317c !important;  color: #fff 
!important;}.label-select-menu .labelstyle-cc317c.selected {  
background:rgba(204, 49, 124, 0.12) !important;  color: #99245c !important;}

span.labelstyle-ff, .linked-labelstyle-ff {  background-color: #ff 
!important;  color: #33 !important;}.labelstyle-ff.selected {  
background-color: #ff !important;  color: #33 
!important;}.label-select-menu .labelstyle-ff.selected {  
background:rgba(255, 255, 255, 0.12) !important;  color: #99 !important;}
  

  

  

  
  https://github.com/lxc/nova-lxd.git;>

  
  https://github.com/lxc/nova-lxd/commits/master.atom; 
rel="alternate" title="Recent Commits to nova-lxd:master" 
type="application/atom+xml">


  


  
Skip to content







  
  
  

https://github.com/; 
data-ga-click="(Logged out) Header, go to homepage, icon:logo-wordmark">
  



Sign up
  Sign in



  
  
This repository

  



  
  
Explore
  
  
Features

Re: [lxc-devel] cgroup V2 and LXC

2016-02-10 Thread Serge Hallyn 
Quoting Christian Brauner (christian.brau...@mailbox.org):
> On Mon, Feb 01, 2016 at 04:56:08AM +, Serge Hallyn wrote:
> > Quoting Kevin Wilson (wkev...@gmail.com):
> > > Hi, LXC developers,
> > > 
> > > The latest kernel release (4.4) includes initial support to cgroup v2
> > > with 2 controllers (memory and io). Also it seems that the PIDs
> > > controller works in cgroup v2, but I do not know if it is officially
> > > supported in v2.
> > > 
> > > Is there any intention to replace the existing cgroup v1 usage in LXC
> > > by cgroup v2 ? or at least to enable working with both of them ?
> > > 
> > > Regards,
> > > Kevin
> > 
> > Replace, no, support, yes.  I've added support for it to cgmanager, and have
> > used lxc with the unified hierarchy through cgmanager.  Without cgmanager
> > it will currently definately not work.  It's worth discussing how we should
> > handle it - and how init wants us to handle it.   With cgmanager I actually
> > built in the support so that you could treat it as a legacy hierarchy, and
> > upstart was happy with that since it used cgmanager.  Systemd will not be
> > happy with that, and it will be a problem.  The only exception to the "no
> > tasks in a non-leaf node" rule is for the / cgroup.  So lxc would need to
> > place init in say /lxc/c1/.leaf, and systemd would have to accept that
> > /lxc/c1 is the container's cgroup.  A few possibilities:
> > 
> > 1. maybe if we place systemd in /lxc/c1/init.scope it will be happy
> Well, here is how I thought it could go (sticking to systemd specifics here):
> - create a slice for all lxc "lxc.slice" (similar to "machine.slice" 
> of
>   systemd-nspawn backed containers)
> - "lxc.slice" contains a scope for each container (e.g. "c1.scope"
> - "c1.scope" contains an "init.scope"
> - "init.scope" only contains the PID of "/sbin/init" as seen from the
>   host (obviously)

So if we are creating container c1, are you talking about

/lxc/c1/lxc.slice/c1.scope/init.scope

or are you talking about a host-global

/lxc.slice

with container-specific

/lxc.slice/c1.scope

per container?

?

> - All other processes are put in another slice "c1-something.slice"

Which other processes?

AFAIK all other processes will be created by systemd.  The q is what will it
do.  If we put systemd in /lxc.slice/c1.scope/init.scope, will it take that
as its cgroup root and try to create and move itself into
/lxc.slice/c1.scope/init.scope ?  If so it will fail since it cannot create a
cgroup while it is in it.

So I think I've convinced myself that we need to collaborate with systemd
on this.  Perhaps we can agree with it on a default cgroup in which it should
be started to tell it "this is the leaf cgroup for your init".  So if it sees
it is in /a/b/c/.cg_leaf, then it will know that /a/b/c is its root.

> If we do not want to create scopes we are left with the option of
> forcing "init" in a separate cgroup from the rest of the containers
> processes.
> 
> Christian
> 
> 
> > 2. maybe we can teach systemd to accept being in a leaf node
> > 3. maybe we can build an exception into cgroup namespaces such that
> > a cgns root also is an exception to the no-tasks-in-non-leaf-nodes
> > rule.  But I doubt that will fly.
> > ___
> > lxc-devel mailing list
> > lxc-devel@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] [PATCH] selftests/cgroupns: new test for cgroup namespaces

2016-02-10 Thread Serge E. Hallyn 
On Sun, Jan 31, 2016 at 06:48:12PM +0100, Alban Crequy wrote:
> From: Alban Crequy 
> 
> This adds the selftest "cgroupns_test" in order to test the CGroup
> Namespace patchset.
> 
> cgroupns_test creates two child processes. They perform a list of
> actions defined by the array cgroupns_test. This array can easily be
> extended to more scenarios without adding much code. They are
> synchronized with eventfds to ensure only one action is performed at a
> time.
> 
> The memory is shared between the processes (CLONE_VM) so each child
> process can know the pid of their siblings without extra IPC.
> 
> The output explains the scenario being played. Short extract:
> 
> > current cgroup: /user.slice/user-0.slice/session-1.scope
> > child process #0: check that process #self (pid=482) has cgroup 
> > /user.slice/user-0.slice/session-1.scope
> > child process #0: unshare cgroupns
> > child process #0: move process #self (pid=482) to cgroup 
> > cgroup-a/subcgroup-a
> > child process #0: join parent cgroupns
> 
> The test does not change the mount namespace and does not mount any
> new cgroup2 filesystem. Therefore this does not test that the cgroup2
> mount is correctly rooted to the cgroupns root at mount time.
> 
> Signed-off-by: Alban Crequy 

Thanks, Alban!

> Acked-by: Serge E. Hallyn 
> 
> ---
> 
> Changelog:
> 20160131 - rebase on sergeh/cgroupns.v10 and fix conflicts
> 
> 20160115 - Detect where cgroup2 is mounted, don't assume
>/sys/fs/cgroup (suggested by sergeh)
>  - Check more error conditions (from krnowak's review)
>  - Coding style (from krnowak's review)
>  - Update error message for Linux >= 4.5 (from krnowak's
>review)
> 
> 20160104 - Fix coding style (from sergeh's review)
>  - Fix printf formatting (from sergeh's review)
>  - Fix parsing of /proc/pid/cgroup (from sergeh's review)
>  - Fix concatenation of cgroup paths
> 
> 20151219 - First version
> 
> This patch is available in the cgroupns.v10-tests branch of
> https://github.com/kinvolk/linux.git
> It is rebased on top of Serge Hallyn's cgroupns.v10 branch of
> https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/
> 
> Test results:
> 
> - SUCCESS on kernel cgroupns.v10 booted with 
> systemd.unified_cgroup_hierarchy=1
> - SUCCESS on kernel cgroupns.v10 booted with 
> systemd.unified_cgroup_hierarchy=0
> ---
>  tools/testing/selftests/Makefile |   1 +
>  tools/testing/selftests/cgroupns/Makefile|  11 +
>  tools/testing/selftests/cgroupns/cgroupns_test.c | 445 
> +++
>  3 files changed, 457 insertions(+)
>  create mode 100644 tools/testing/selftests/cgroupns/Makefile
>  create mode 100644 tools/testing/selftests/cgroupns/cgroupns_test.c
> 
> diff --git a/tools/testing/selftests/Makefile 
> b/tools/testing/selftests/Makefile
> index b04afc3..b373135 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -1,5 +1,6 @@
>  TARGETS = breakpoints
>  TARGETS += capabilities
> +TARGETS += cgroupns
>  TARGETS += cpu-hotplug
>  TARGETS += efivarfs
>  TARGETS += exec
> diff --git a/tools/testing/selftests/cgroupns/Makefile 
> b/tools/testing/selftests/cgroupns/Makefile
> new file mode 100644
> index 000..0fdbe0a
> --- /dev/null
> +++ b/tools/testing/selftests/cgroupns/Makefile
> @@ -0,0 +1,11 @@
> +CFLAGS += -I../../../../usr/include/
> +CFLAGS += -I../../../../include/uapi/
> +
> +all: cgroupns_test
> +
> +TEST_PROGS := cgroupns_test
> +
> +include ../lib.mk
> +
> +clean:
> + $(RM) cgroupns_test
> diff --git a/tools/testing/selftests/cgroupns/cgroupns_test.c 
> b/tools/testing/selftests/cgroupns/cgroupns_test.c
> new file mode 100644
> index 000..71e2336
> --- /dev/null
> +++ b/tools/testing/selftests/cgroupns/cgroupns_test.c
> @@ -0,0 +1,445 @@
> +#define _GNU_SOURCE
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "../kselftest.h"
> +
> +#define STACK_SIZE 65536
> +
> +static char cgroup_mountpoint[4096];
> +static char root_cgroup[4096];
> +
> +#define CHILDREN_COUNT 2
> +typedef struct {
> + pid_t pid;
> + uint8_t *stack;
> + int start_semfd;
> + int end_semfd;
> +} cgroupns_child_t;
> +cgroupns_child_t children[CHILDREN_COUNT];
> +
> +typedef enum {
> + UNSHARE_CGROUPNS,
> + JOIN_CGROUPNS,
> + CHECK_CGROUP,
> + CHECK_CGROUP_WITH_ROOT_PREFIX,
> + MOVE_CGROUP,
> + MOVE_CGROUP_WITH_ROOT_PREFIX,
> +} cgroupns_action_t;
> +
> +static const struct {
> + int actor_id;
> + cgroupns_action_t action;
> + int target_id;
> + char *path;
> +} cgroupns_tests[] = {
> + { 0, CHECK_CGROUP_WITH_ROOT_PREFIX, -1, "/"},
> + { 0,

Re: [lxc-devel] cgroup V2 and LXC

2016-02-10 Thread Christian Brauner 
On Wed, Feb 10, 2016 at 05:45:48PM +, Serge Hallyn wrote:
> Quoting Christian Brauner (christian.brau...@mailbox.org):
> > On Mon, Feb 01, 2016 at 04:56:08AM +, Serge Hallyn wrote:
> > > Quoting Kevin Wilson (wkev...@gmail.com):
> > > > Hi, LXC developers,
> > > > 
> > > > The latest kernel release (4.4) includes initial support to cgroup v2
> > > > with 2 controllers (memory and io). Also it seems that the PIDs
> > > > controller works in cgroup v2, but I do not know if it is officially
> > > > supported in v2.
> > > > 
> > > > Is there any intention to replace the existing cgroup v1 usage in LXC
> > > > by cgroup v2 ? or at least to enable working with both of them ?
> > > > 
> > > > Regards,
> > > > Kevin
> > > 
> > > Replace, no, support, yes.  I've added support for it to cgmanager, and 
> > > have
> > > used lxc with the unified hierarchy through cgmanager.  Without cgmanager
> > > it will currently definately not work.  It's worth discussing how we 
> > > should
> > > handle it - and how init wants us to handle it.   With cgmanager I 
> > > actually
> > > built in the support so that you could treat it as a legacy hierarchy, and
> > > upstart was happy with that since it used cgmanager.  Systemd will not be
> > > happy with that, and it will be a problem.  The only exception to the "no
> > > tasks in a non-leaf node" rule is for the / cgroup.  So lxc would need to
> > > place init in say /lxc/c1/.leaf, and systemd would have to accept that
> > > /lxc/c1 is the container's cgroup.  A few possibilities:
> > > 
> > > 1. maybe if we place systemd in /lxc/c1/init.scope it will be happy
> > Well, here is how I thought it could go (sticking to systemd specifics 
> > here):
> > - create a slice for all lxc "lxc.slice" (similar to 
> > "machine.slice" of
> >   systemd-nspawn backed containers)
> > - "lxc.slice" contains a scope for each container (e.g. "c1.scope"
> > - "c1.scope" contains an "init.scope"
> > - "init.scope" only contains the PID of "/sbin/init" as seen from 
> > the
> >   host (obviously)
> 
> So if we are creating container c1, are you talking about
> 
> /lxc/c1/lxc.slice/c1.scope/init.scope
> 
> or are you talking about a host-global
> 
> /lxc.slice
Yes, you have lxc.slice then you have all your machines under this. This is what
systemd-nspawn does if I'm not mistaken.
> 
> with container-specific
> 
> /lxc.slice/c1.scope
> 
> per container?
> 
> ?
Yes.
> 
> > - All other processes are put in another slice "c1-something.slice"
> 
> Which other processes?
Well, all processes, systemd starts are either put in system.slice or
user.slice. All other things we start in the container (let it be e.g. vim) is
put in a session.slice (e.g. session-0.slice, session-1000.slice).
> 
> AFAIK all other processes will be created by systemd.  The q is what will it
> do.  If we put systemd in /lxc.slice/c1.scope/init.scope, will it take that
> as its cgroup root and try to create and move itself into
> /lxc.slice/c1.scope/init.scope ?  If so it will fail since it cannot create a
> cgroup while it is in it.
I don't think so but I need to test that again. Time to boot unified.

> 
> So I think I've convinced myself that we need to collaborate with systemd
> on this.  Perhaps we can agree with it on a default cgroup in which it should
> be started to tell it "this is the leaf cgroup for your init".  So if it sees
> it is in /a/b/c/.cg_leaf, then it will know that /a/b/c is its root.
I thought the same that's why I started to read some of the code.
fwiw, systemd-nspawn already works with the unified cgroup hierarchy and I think
nesting works as well. But I'm not completely sure how nspawn handles nesting.

> 
> > If we do not want to create scopes we are left with the option of
> > forcing "init" in a separate cgroup from the rest of the containers
> > processes.
> > 
> > Christian
> > 
> > 
> > > 2. maybe we can teach systemd to accept being in a leaf node
> > > 3. maybe we can build an exception into cgroup namespaces such that
> > > a cgns root also is an exception to the no-tasks-in-non-leaf-nodes
> > > rule.  But I doubt that will fly.
> > > ___
> > > lxc-devel mailing list
> > > lxc-devel@lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-devel
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

[lxc-devel] [lxc/lxc] 2c5f2e: lxc-destroy: deal with ephemeral containers

2016-02-10 Thread GitHub 
  Branch: refs/heads/master
  Home:   https://github.com/lxc/lxc
  Commit: 2c5f2edeb91100b8debfec90624cd1fe20ee5a8d
  https://github.com/lxc/lxc/commit/2c5f2edeb91100b8debfec90624cd1fe20ee5a8d
  Author: Christian Brauner 
  Date:   2016-02-10 (Wed, 10 Feb 2016)

  Changed paths:
M src/lxc/lxc_destroy.c
M src/lxc/start.c

  Log Message:
  ---
  lxc-destroy: deal with ephemeral containers

- Ephemeral containers are destroyed on shutdown so we do not destroy them.
- Destroy ephemeral containers with clones: first destroy all the clones, then
  destroy the container.
- Ephemeral containers with snapshots cannot be easily handled but we can
  probably trust that no one will try to make snapshots of an ephemeral
  container.

Signed-off-by: Christian Brauner 


  Commit: bad548de3ba42d501fe8604debadcce4031dda34
  https://github.com/lxc/lxc/commit/bad548de3ba42d501fe8604debadcce4031dda34
  Author: Serge Hallyn 
  Date:   2016-02-10 (Wed, 10 Feb 2016)

  Changed paths:
M src/lxc/lxc_destroy.c
M src/lxc/start.c

  Log Message:
  ---
  Merge pull request #813 from brauner/2016-02-01/lxc_destroy_ephemeral

lxc-destroy: deal with ephemeral containers


Compare: https://github.com/lxc/lxc/compare/cd30b4fa22e6...bad548de3ba4___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Packaging lxc 1.0.x for CentOS 7

2016-02-10 Thread Johannes Kastl 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Am 08.02.16 schrieb Nehal J Wani:
> When I compiled lxc from source on CentOS 7, I had to edit the
> file: /usr/local/etc/sysconfig/lxc and change the value
> USE_LXC_BRIDGE to 'true' and then type:
> /usr/local/libexec/lxc/lxc-net start

Sure that you compiled a 1.0.x? I only get this file when compiling
1.1.x releases...

Johannes

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAla7iToACgkQzi3gQ/xETbKJ1gCeMN12JHCzZj9A1sL9clNeHQ5S
s7AAnR/ou8L+WTTO07UKOLSZUi99syon
=MKDr
-END PGP SIGNATURE-
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Re: [lxc-devel] Packaging lxc 1.0.x for CentOS 7

2016-02-10 Thread Nehal J Wani 
Oh, I also did: mkdir /usr/local/var/lib/misc/
Yes, I tested it on both, lxc-2.0.0.beta2 and lxc-1.1.5

On Thu, Feb 11, 2016 at 12:32 AM, Johannes Kastl  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Am 08.02.16 schrieb Nehal J Wani:
>> When I compiled lxc from source on CentOS 7, I had to edit the
>> file: /usr/local/etc/sysconfig/lxc and change the value
>> USE_LXC_BRIDGE to 'true' and then type:
>> /usr/local/libexec/lxc/lxc-net start
>
> Sure that you compiled a 1.0.x? I only get this file when compiling
> 1.1.x releases...
>
> Johannes
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/
>
> iEYEARECAAYFAla7iToACgkQzi3gQ/xETbKJ1gCeMN12JHCzZj9A1sL9clNeHQ5S
> s7AAnR/ou8L+WTTO07UKOLSZUi99syon
> =MKDr
> -END PGP SIGNATURE-
> ___
> lxc-devel mailing list
> lxc-devel@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel



-- 
Nehal J Wani
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel