Re: [lxc-devel] [PATCH 1/2] Add mount hook script to provide systemd containers with minimal /dev
Quoting Alexander Vladimirov (alexander.idkfa.vladimi...@gmail.com):
Is there any reason why the lxc.autodev config option
(in git://github.com/lxc/lxc.git#staging) does not suffice?
-serge
> ---
> Makefile.am | 4 ++--
> configure.ac | 4
> hooks/Makefile.am | 4
> hooks/mount.in| 11 +++
> 4 files changed, 21 insertions(+), 2 deletions(-)
> create mode 100644 hooks/Makefile.am
> create mode 100644 hooks/mount.in
>
> diff --git a/Makefile.am b/Makefile.am
> index 05a03f4..b424f2e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -2,8 +2,8 @@
>
> ACLOCAL_AMFLAGS = -I config
>
> -SUBDIRS = src templates doc
> -DIST_SUBDIRS = config src templates doc
> +SUBDIRS = src hooks templates doc
> +DIST_SUBDIRS = config src hooks templates doc
> EXTRA_DIST = autogen.sh lxc.spec CONTRIBUTING MAINTAINERS ChangeLog
>
> pcdatadir = $(libdir)/pkgconfig
> diff --git a/configure.ac b/configure.ac
> index 900e1e7..2d4365f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -73,6 +73,7 @@ AS_AC_EXPAND(LXC_GENERATE_DATE, "$(date)")
> AS_AC_EXPAND(LXCPATH, "${with_config_path}")
> AS_AC_EXPAND(LXCROOTFSMOUNT, "${with_rootfs_path}")
> AS_AC_EXPAND(LXCTEMPLATEDIR, ['${datadir}/lxc/templates'])
> +AS_AC_EXPAND(LXCHOOKDIR, ['${datadir}/lxc/hooks'])
>
> AC_SUBST(LXCINITDIR, ['${libexecdir}'])
>
> @@ -158,6 +159,9 @@ AC_CONFIG_FILES([
> templates/lxc-sshd
> templates/lxc-archlinux
>
> + hooks/Makefile
> + hooks/mount
> +
> src/Makefile
> src/lxc/Makefile
> src/lxc/lxc-ps
> diff --git a/hooks/Makefile.am b/hooks/Makefile.am
> new file mode 100644
> index 000..8fbf97c
> --- /dev/null
> +++ b/hooks/Makefile.am
> @@ -0,0 +1,4 @@
> +hooksdir=@LXCHOOKDIR@
> +
> +hooks_SCRIPTS = \
> + mount
> diff --git a/hooks/mount.in b/hooks/mount.in
> new file mode 100644
> index 000..46c001e
> --- /dev/null
> +++ b/hooks/mount.in
> @@ -0,0 +1,11 @@
> +#!/bin/sh
> +
> +dev_path="/usr/lib/lxc/rootfs/dev"
> +mkdir -p "${dev_path}/pts"
> +mknod -m 666 "${dev_path}/null" c 1 3
> +mknod -m 666 "${dev_path}/zero" c 1 5
> +mknod -m 666 "${dev_path}/full" c 1 7
> +mknod -m 666 "${dev_path}/random" c 1 8
> +mknod -m 666 "${dev_path}/urandom" c 1 9
> +mknod -m 666 "${dev_path}/tty" c 5 0
> +mknod -m 600 "${dev_path}/console" c 5 1
> --
> 1.8.0.1
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] API wishlist
Quoting Frederic Crozat (fcro...@suse.com): > I have to agree with that proposal (and making configuration path being > optionally a different path than the one used for rootfs would be a > plus, like the patch Alexey has been posting for a long time and we are > using on SLES). Can you post a URL? -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/2] Add mount hook script to provide systemd containers with minimal /dev
I don't believe this is the right way to fix your problem.
Serge and Michael spent quite a while discussing this issue and coming
up with lxc.autodev that's been merged a couple of weeks ago in the
staging branch and does pretty much the same thing as your change, but
the "right way" directly in lxc-start.
On 12/10/2012 12:33 AM, Alexander Vladimirov wrote:
> ---
> Makefile.am | 4 ++--
> configure.ac | 4
> hooks/Makefile.am | 4
> hooks/mount.in| 11 +++
> 4 files changed, 21 insertions(+), 2 deletions(-)
> create mode 100644 hooks/Makefile.am
> create mode 100644 hooks/mount.in
>
> diff --git a/Makefile.am b/Makefile.am
> index 05a03f4..b424f2e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -2,8 +2,8 @@
>
> ACLOCAL_AMFLAGS = -I config
>
> -SUBDIRS = src templates doc
> -DIST_SUBDIRS = config src templates doc
> +SUBDIRS = src hooks templates doc
> +DIST_SUBDIRS = config src hooks templates doc
> EXTRA_DIST = autogen.sh lxc.spec CONTRIBUTING MAINTAINERS ChangeLog
>
> pcdatadir = $(libdir)/pkgconfig
> diff --git a/configure.ac b/configure.ac
> index 900e1e7..2d4365f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -73,6 +73,7 @@ AS_AC_EXPAND(LXC_GENERATE_DATE, "$(date)")
> AS_AC_EXPAND(LXCPATH, "${with_config_path}")
> AS_AC_EXPAND(LXCROOTFSMOUNT, "${with_rootfs_path}")
> AS_AC_EXPAND(LXCTEMPLATEDIR, ['${datadir}/lxc/templates'])
> +AS_AC_EXPAND(LXCHOOKDIR, ['${datadir}/lxc/hooks'])
>
> AC_SUBST(LXCINITDIR, ['${libexecdir}'])
>
> @@ -158,6 +159,9 @@ AC_CONFIG_FILES([
> templates/lxc-sshd
> templates/lxc-archlinux
>
> + hooks/Makefile
> + hooks/mount
> +
> src/Makefile
> src/lxc/Makefile
> src/lxc/lxc-ps
> diff --git a/hooks/Makefile.am b/hooks/Makefile.am
> new file mode 100644
> index 000..8fbf97c
> --- /dev/null
> +++ b/hooks/Makefile.am
> @@ -0,0 +1,4 @@
> +hooksdir=@LXCHOOKDIR@
> +
> +hooks_SCRIPTS = \
> + mount
> diff --git a/hooks/mount.in b/hooks/mount.in
> new file mode 100644
> index 000..46c001e
> --- /dev/null
> +++ b/hooks/mount.in
> @@ -0,0 +1,11 @@
> +#!/bin/sh
> +
> +dev_path="/usr/lib/lxc/rootfs/dev"
> +mkdir -p "${dev_path}/pts"
> +mknod -m 666 "${dev_path}/null" c 1 3
> +mknod -m 666 "${dev_path}/zero" c 1 5
> +mknod -m 666 "${dev_path}/full" c 1 7
> +mknod -m 666 "${dev_path}/random" c 1 8
> +mknod -m 666 "${dev_path}/urandom" c 1 9
> +mknod -m 666 "${dev_path}/tty" c 5 0
> +mknod -m 600 "${dev_path}/console" c 5 1
>
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: OpenPGP digital signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] API wishlist
On Fri, 07 Dec 2012 12:47:59 -0500 Stéphane Graber wrote: > On 12/07/2012 12:25 PM, Serge Hallyn wrote: > > Quoting Stéphane Graber (stgra...@ubuntu.com): > > ... > >> - get_version() (not container specific) > >> - get_lxc_path() (not container specific) > >>Returns the storage path for the containers. > >>Defaults to LXCPATH. > >> - set_lxc_path(path) (not container specific) > >> > >> > >> Looking at my todolist for this cycle, the highest priority ones > >> for me would be: > >> 1) get_lxc_path() > >> 2) set_lxc_path() > >> 3) get_cgroup_item() > >> 4) set_cgroup_item() > > > > How would set_lxc_path() work? Would all the lxc code be switched > > to check /etc/default/lxc.conf for the value, and autoconf would > > only fill in the value in that file? > > So I think we should split the implementation in two: > 1) Stop hardcoding LXCPATH in all the C code, instead make it default > to LXCPATH and overrideable by the set_lxc_path() call. > 2) Discuss implementing a system wide, not container specific, lxc > configuration file to be used by all distros in a format that's easily > parsable. For 2, doesn't f0e592fc do that? > Implementing 1) will make it easy for individual commands like > lxc-list to implement an extra argument letting the user override the > lookup path. It'll also make it much easier to deal with lxc being > run as a user at some point in the future. > > Obviously, once we have that, some people will want to change the > default lookup location in one place and have all the commands use > that path. That's where we need 2) so that we can store that kind of > settings in a way that's not distro-specific and have all the tools > in all the different languages to parse that file. > > > -serge > > > > -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] API wishlist
On 12/10/2012 09:30 AM, Dwight Engen wrote: > On Fri, 07 Dec 2012 12:47:59 -0500 > Stéphane Graber wrote: > >> On 12/07/2012 12:25 PM, Serge Hallyn wrote: >>> Quoting Stéphane Graber (stgra...@ubuntu.com): >>> ... - get_version() (not container specific) - get_lxc_path() (not container specific) Returns the storage path for the containers. Defaults to LXCPATH. - set_lxc_path(path) (not container specific) Looking at my todolist for this cycle, the highest priority ones for me would be: 1) get_lxc_path() 2) set_lxc_path() 3) get_cgroup_item() 4) set_cgroup_item() >>> >>> How would set_lxc_path() work? Would all the lxc code be switched >>> to check /etc/default/lxc.conf for the value, and autoconf would >>> only fill in the value in that file? >> >> So I think we should split the implementation in two: >> 1) Stop hardcoding LXCPATH in all the C code, instead make it default >> to LXCPATH and overrideable by the set_lxc_path() call. >> 2) Discuss implementing a system wide, not container specific, lxc >> configuration file to be used by all distros in a format that's easily >> parsable. > > For 2, doesn't f0e592fc do that? f0e592fc is more of a bare config that's copied over to every new container than a lxc system configuration file. If we were to add the lxcpath to /etc/lxc/lxc.conf, it'd end up being added to every new container's configuration where it'd be rather useless. I think the naming of /etc/lxc/lxc.conf was rather bad and I should have thought of that back then :) Essentially our current /etc/lxc/lxc.conf should really be /etc/lxc/default.conf, clearly identifying that it's the default configuration for new containers. Then we could use /etc/lxc/lxc.conf for configuration specific to the lxc tools. If that makes sense to everyone else, I think it'd still be possible to change that for alpha2. I expect it to be mostly difficult for Ubuntu users as we've had /etc/lxc/lxc.conf for the past few years, but that's nothing we can't magically figure out and transition in package maintainer scripts. >> Implementing 1) will make it easy for individual commands like >> lxc-list to implement an extra argument letting the user override the >> lookup path. It'll also make it much easier to deal with lxc being >> run as a user at some point in the future. >> >> Obviously, once we have that, some people will want to change the >> default lookup location in one place and have all the commands use >> that path. That's where we need 2) so that we can store that kind of >> settings in a way that's not distro-specific and have all the tools >> in all the different languages to parse that file. >> >>> -serge >>> >> >> > -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP digital signature -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] API wishlist
On Mon, 10 Dec 2012 09:44:26 -0500 Stéphane Graber wrote: > On 12/10/2012 09:30 AM, Dwight Engen wrote: > > On Fri, 07 Dec 2012 12:47:59 -0500 > > Stéphane Graber wrote: > > > >> On 12/07/2012 12:25 PM, Serge Hallyn wrote: > >>> Quoting Stéphane Graber (stgra...@ubuntu.com): > >>> ... > - get_version() (not container specific) > - get_lxc_path() (not container specific) > Returns the storage path for the containers. > Defaults to LXCPATH. > - set_lxc_path(path) (not container specific) > > > Looking at my todolist for this cycle, the highest priority ones > for me would be: > 1) get_lxc_path() > 2) set_lxc_path() > 3) get_cgroup_item() > 4) set_cgroup_item() > >>> > >>> How would set_lxc_path() work? Would all the lxc code be switched > >>> to check /etc/default/lxc.conf for the value, and autoconf would > >>> only fill in the value in that file? > >> > >> So I think we should split the implementation in two: > >> 1) Stop hardcoding LXCPATH in all the C code, instead make it > >> default to LXCPATH and overrideable by the set_lxc_path() call. > >> 2) Discuss implementing a system wide, not container specific, lxc > >> configuration file to be used by all distros in a format that's > >> easily parsable. > > > > For 2, doesn't f0e592fc do that? > > f0e592fc is more of a bare config that's copied over to every new > container than a lxc system configuration file. > > If we were to add the lxcpath to /etc/lxc/lxc.conf, it'd end up being > added to every new container's configuration where it'd be rather > useless. > > I think the naming of /etc/lxc/lxc.conf was rather bad and I should > have thought of that back then :) > Essentially our current /etc/lxc/lxc.conf should really be > /etc/lxc/default.conf, clearly identifying that it's the default > configuration for new containers. > Then we could use /etc/lxc/lxc.conf for configuration specific to the > lxc tools. Ahh, yes I see the distinction. I think your proposal makes sense. > If that makes sense to everyone else, I think it'd still be possible > to change that for alpha2. I expect it to be mostly difficult for > Ubuntu users as we've had /etc/lxc/lxc.conf for the past few years, > but that's nothing we can't magically figure out and transition in > package maintainer scripts. > > >> Implementing 1) will make it easy for individual commands like > >> lxc-list to implement an extra argument letting the user override > >> the lookup path. It'll also make it much easier to deal with lxc > >> being run as a user at some point in the future. > >> > >> Obviously, once we have that, some people will want to change the > >> default lookup location in one place and have all the commands use > >> that path. That's where we need 2) so that we can store that kind > >> of settings in a way that's not distro-specific and have all the > >> tools in all the different languages to parse that file. > >> > >>> -serge > >>> > >> > >> > > > > -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] API wishlist
Quoting Dwight Engen (dwight.en...@oracle.com): > > I think the naming of /etc/lxc/lxc.conf was rather bad and I should > > have thought of that back then :) > > Essentially our current /etc/lxc/lxc.conf should really be > > /etc/lxc/default.conf, clearly identifying that it's the default > > configuration for new containers. > > Then we could use /etc/lxc/lxc.conf for configuration specific to the > > lxc tools. > > Ahh, yes I see the distinction. I think your proposal makes sense. +1 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC 0.9.alpha1
On 12/05/2012 11:54 AM, Stéphane Graber wrote: > Hello, > > After discussing this briefly with Daniel, I wanted to make all of you > aware that we are currently planning on sending a pull request of the > staging branch on the 10th of December (next Monday). > > This pull request will very likely contain everything that's currently > in the staging branch and is intended to become 0.9.alpha1. > > I'd therefore recommend everyone tests the current staging branch and > sends any remaining bugfixes to the mailing list as soon as possible. > > Also, if a change you sent to the mailing-list hasn't been applied yet, > it's very likely because I missed it as according to my mail client, > there's no outstanding patch to review. In such case, please reply to > this e-mail with a reference to your change and I'll make sure it's > reviewed before I send the pull request. > > Thanks As far as I'm concerned, the staging branch is now ready for the release of 0.9.alpha1. I plan on sending the merge proposal later this afternoon (in 5-6 hours) after I've run some more tests on it. Test packages for Ubuntu can be found at: https://code.launchpad.net/~ubuntu-lxc/+archive/daily/+packages If you're aware of any critical bug currently affecting staging, please speak up now :) -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP digital signature -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC 0.9.alpha1
On Mon, 10 Dec 2012 10:35:17 -0500
Stéphane Graber wrote:
> On 12/05/2012 11:54 AM, Stéphane Graber wrote:
> > Hello,
> >
> > After discussing this briefly with Daniel, I wanted to make all of
> > you aware that we are currently planning on sending a pull request
> > of the staging branch on the 10th of December (next Monday).
> >
> > This pull request will very likely contain everything that's
> > currently in the staging branch and is intended to become
> > 0.9.alpha1.
> >
> > I'd therefore recommend everyone tests the current staging branch
> > and sends any remaining bugfixes to the mailing list as soon as
> > possible.
> >
> > Also, if a change you sent to the mailing-list hasn't been applied
> > yet, it's very likely because I missed it as according to my mail
> > client, there's no outstanding patch to review. In such case,
> > please reply to this e-mail with a reference to your change and
> > I'll make sure it's reviewed before I send the pull request.
> >
> > Thanks
>
> As far as I'm concerned, the staging branch is now ready for the
> release of 0.9.alpha1.
>
> I plan on sending the merge proposal later this afternoon
> (in 5-6 hours) after I've run some more tests on it.
>
> Test packages for Ubuntu can be found at:
> https://code.launchpad.net/~ubuntu-lxc/+archive/daily/+packages
>
>
> If you're aware of any critical bug currently affecting staging,
> please speak up now :)
Its not critical, but I think the above patch that replaces @LXCPATH@
with %{_localstatedir}/* in the spec file should go in to fix building
on Fedora. It'd be nice to hear an ack from Michael though :)
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC 0.9.alpha1
On Mon, 2012-12-10 at 12:09 -0500, Dwight Engen wrote:
> On Mon, 10 Dec 2012 10:35:17 -0500
> Stéphane Graber wrote:
>
> > On 12/05/2012 11:54 AM, Stéphane Graber wrote:
> > > Hello,
> > >
> > > After discussing this briefly with Daniel, I wanted to make all of
> > > you aware that we are currently planning on sending a pull request
> > > of the staging branch on the 10th of December (next Monday).
> > >
> > > This pull request will very likely contain everything that's
> > > currently in the staging branch and is intended to become
> > > 0.9.alpha1.
> > >
> > > I'd therefore recommend everyone tests the current staging branch
> > > and sends any remaining bugfixes to the mailing list as soon as
> > > possible.
> > >
> > > Also, if a change you sent to the mailing-list hasn't been applied
> > > yet, it's very likely because I missed it as according to my mail
> > > client, there's no outstanding patch to review. In such case,
> > > please reply to this e-mail with a reference to your change and
> > > I'll make sure it's reviewed before I send the pull request.
> > >
> > > Thanks
> >
> > As far as I'm concerned, the staging branch is now ready for the
> > release of 0.9.alpha1.
> >
> > I plan on sending the merge proposal later this afternoon
> > (in 5-6 hours) after I've run some more tests on it.
> >
> > Test packages for Ubuntu can be found at:
> > https://code.launchpad.net/~ubuntu-lxc/+archive/daily/+packages
> >
> >
> > If you're aware of any critical bug currently affecting staging,
> > please speak up now :)
> Its not critical, but I think the above patch that replaces @LXCPATH@
> with %{_localstatedir}/* in the spec file should go in to fix building
> on Fedora. It'd be nice to hear an ack from Michael though :)
Aaaa! I meant to test that patch and got distracted. Just tested.
Everything worked and the builds went fine on F17. I'm good with it.
The current staging plus that change builds Fedora rpms just fine.
Acked-by: Michael H. Warfield
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC 0.9.alpha1
On 12/10/2012 12:30 PM, Michael H. Warfield wrote:
> On Mon, 2012-12-10 at 12:09 -0500, Dwight Engen wrote:
>> On Mon, 10 Dec 2012 10:35:17 -0500
>> Stéphane Graber wrote:
>>
>>> On 12/05/2012 11:54 AM, Stéphane Graber wrote:
Hello,
After discussing this briefly with Daniel, I wanted to make all of
you aware that we are currently planning on sending a pull request
of the staging branch on the 10th of December (next Monday).
This pull request will very likely contain everything that's
currently in the staging branch and is intended to become
0.9.alpha1.
I'd therefore recommend everyone tests the current staging branch
and sends any remaining bugfixes to the mailing list as soon as
possible.
Also, if a change you sent to the mailing-list hasn't been applied
yet, it's very likely because I missed it as according to my mail
client, there's no outstanding patch to review. In such case,
please reply to this e-mail with a reference to your change and
I'll make sure it's reviewed before I send the pull request.
Thanks
>>>
>>> As far as I'm concerned, the staging branch is now ready for the
>>> release of 0.9.alpha1.
>>>
>>> I plan on sending the merge proposal later this afternoon
>>> (in 5-6 hours) after I've run some more tests on it.
>>>
>>> Test packages for Ubuntu can be found at:
>>> https://code.launchpad.net/~ubuntu-lxc/+archive/daily/+packages
>>>
>>>
>>> If you're aware of any critical bug currently affecting staging,
>>> please speak up now :)
>
>> Its not critical, but I think the above patch that replaces @LXCPATH@
>> with %{_localstatedir}/* in the spec file should go in to fix building
>> on Fedora. It'd be nice to hear an ack from Michael though :)
>
> Aaaa! I meant to test that patch and got distracted. Just tested.
> Everything worked and the builds went fine on F17. I'm good with it.
> The current staging plus that change builds Fedora rpms just fine.
>
> Acked-by: Michael H. Warfield
>
> Regards,
> Mike
Took a bit of digging to find what patch you were referring to but I
think I picked up the right one and pushed to staging :)
Thanks
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: OpenPGP digital signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC 0.9.alpha1
On Mon, 2012-12-10 at 12:36 -0500, Stéphane Graber wrote:
> On 12/10/2012 12:30 PM, Michael H. Warfield wrote:
> > On Mon, 2012-12-10 at 12:09 -0500, Dwight Engen wrote:
> >> On Mon, 10 Dec 2012 10:35:17 -0500
> >> Stéphane Graber wrote:
> >>
> >>> On 12/05/2012 11:54 AM, Stéphane Graber wrote:
> Hello,
>
> After discussing this briefly with Daniel, I wanted to make all of
> you aware that we are currently planning on sending a pull request
> of the staging branch on the 10th of December (next Monday).
>
> This pull request will very likely contain everything that's
> currently in the staging branch and is intended to become
> 0.9.alpha1.
>
> I'd therefore recommend everyone tests the current staging branch
> and sends any remaining bugfixes to the mailing list as soon as
> possible.
>
> Also, if a change you sent to the mailing-list hasn't been applied
> yet, it's very likely because I missed it as according to my mail
> client, there's no outstanding patch to review. In such case,
> please reply to this e-mail with a reference to your change and
> I'll make sure it's reviewed before I send the pull request.
>
> Thanks
> >>>
> >>> As far as I'm concerned, the staging branch is now ready for the
> >>> release of 0.9.alpha1.
> >>>
> >>> I plan on sending the merge proposal later this afternoon
> >>> (in 5-6 hours) after I've run some more tests on it.
> >>>
> >>> Test packages for Ubuntu can be found at:
> >>> https://code.launchpad.net/~ubuntu-lxc/+archive/daily/+packages
> >>>
> >>>
> >>> If you're aware of any critical bug currently affecting staging,
> >>> please speak up now :)
> >
> >> Its not critical, but I think the above patch that replaces @LXCPATH@
> >> with %{_localstatedir}/* in the spec file should go in to fix building
> >> on Fedora. It'd be nice to hear an ack from Michael though :)
> >
> > Aaaa! I meant to test that patch and got distracted. Just tested.
> > Everything worked and the builds went fine on F17. I'm good with it.
> > The current staging plus that change builds Fedora rpms just fine.
> >
> > Acked-by: Michael H. Warfield
> >
> > Regards,
> > Mike
> Took a bit of digging to find what patch you were referring to but I
> think I picked up the right one and pushed to staging :)
Tested. And we are good. Only thing in there is adjusting for the
version number (it currently claims 0.8.0) but that's normal for any
build spec in my experience.
> Thanks
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC 0.9.alpha1
On 12/10/2012 12:59 PM, Michael H. Warfield wrote:
> On Mon, 2012-12-10 at 12:36 -0500, Stéphane Graber wrote:
>> On 12/10/2012 12:30 PM, Michael H. Warfield wrote:
>>> On Mon, 2012-12-10 at 12:09 -0500, Dwight Engen wrote:
On Mon, 10 Dec 2012 10:35:17 -0500
Stéphane Graber wrote:
> On 12/05/2012 11:54 AM, Stéphane Graber wrote:
>> Hello,
>>
>> After discussing this briefly with Daniel, I wanted to make all of
>> you aware that we are currently planning on sending a pull request
>> of the staging branch on the 10th of December (next Monday).
>>
>> This pull request will very likely contain everything that's
>> currently in the staging branch and is intended to become
>> 0.9.alpha1.
>>
>> I'd therefore recommend everyone tests the current staging branch
>> and sends any remaining bugfixes to the mailing list as soon as
>> possible.
>>
>> Also, if a change you sent to the mailing-list hasn't been applied
>> yet, it's very likely because I missed it as according to my mail
>> client, there's no outstanding patch to review. In such case,
>> please reply to this e-mail with a reference to your change and
>> I'll make sure it's reviewed before I send the pull request.
>>
>> Thanks
>
> As far as I'm concerned, the staging branch is now ready for the
> release of 0.9.alpha1.
>
> I plan on sending the merge proposal later this afternoon
> (in 5-6 hours) after I've run some more tests on it.
>
> Test packages for Ubuntu can be found at:
> https://code.launchpad.net/~ubuntu-lxc/+archive/daily/+packages
>
>
> If you're aware of any critical bug currently affecting staging,
> please speak up now :)
>>>
Its not critical, but I think the above patch that replaces @LXCPATH@
with %{_localstatedir}/* in the spec file should go in to fix building
on Fedora. It'd be nice to hear an ack from Michael though :)
>>>
>>> Aaaa! I meant to test that patch and got distracted. Just tested.
>>> Everything worked and the builds went fine on F17. I'm good with it.
>>> The current staging plus that change builds Fedora rpms just fine.
>>>
>>> Acked-by: Michael H. Warfield
>>>
>>> Regards,
>>> Mike
>
>> Took a bit of digging to find what patch you were referring to but I
>> think I picked up the right one and pushed to staging :)
>
> Tested. And we are good. Only thing in there is adjusting for the
> version number (it currently claims 0.8.0) but that's normal for any
> build spec in my experience.
>
>> Thanks
>
> Regards,
> Mike
Good.
The plan is to send the pull-request without the commit changing the
version number and let Daniel pull and add that commit.
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: OpenPGP digital signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] LXC 0.9.alpha1 pull request
Hi Daniel, You'll find the 0.9.alpha1 pull request below. Based on what you had to do last time in Copenhagen, I believe the following actions are to be done on your side: - Properly tag 0.8, currently we only have a commit but no matching tag, this should be fixed before pulling from staging. - Review the pull request - Use "git pull --edit --no-ff --stat git://github.com/lxc/lxc.git", that should do a real merge, letting you do a proper Sign-off of the changes. - Update the version number to 0.9.alpha1 (the version number format is to avoid breaking RPM based distros) - Commit and tag Major changes include: - Introduction of the new liblxc API - Python bindings - New tools: - lxc-device - lxc-start-ephemeral - python version of lxc-ls - lxc.autodev support - oracle template - reworked lxc-attach - /etc/lxc/lxc.conf configuration - Switch to new docbook - A lot of other improvements, new features and bugfixes (details below) I've been using the staging branch daily for the past few months and as far as I can tell, all the issues I noticed have been fixed. All of Serge's tests have also passed against today's staging branch and same thing for the few tests I usually run here, so it should be a pretty solid alpha release :) Thanks to everyone involved! Stéphane The following changes since commit 4aa7ac35696b87867b1e85410a80527696ff4d64: Version 0.8.0 (2012-11-11 03:34:22 +0100) are available in the git repository at: git://github.com/lxc/lxc.git staging for you to fetch changes up to 7323456ec3efe23bb7a84164d3e71d4293998f2c: assume LXCPATH took on default localstatedir based value in configure (2012-12-10 12:34:53 -0500) Christian Seiler (6): lxc-start: Add command to retrieve the clone flags used to start the container. lxc-attach: Remodel cgroup attach logic and attach to namespaces again in parent process lxc-attach: Detect which namespaces to attach to dynamically lxc-unshare: Move functions to determine clone flags from command line options to namespace.c lxc-attach: Add -s option to select namespaces to attach to lxc-attach: Add -R option to remount /sys and /proc when only partially attaching Diego Elio Pettenò (1): build: make sure to expand all variables that are substituted. Dwight Engen (29): fix compile without apparmor (against git staging) fix gcc error: typedef redefinition (against git staging) fix expansion of LXCPATH,LXCROOTFSMOUNT,LXCTEMPLATEDIR fix minor spelling error Better rpm database downgrade logic Always rebuild rpm database Fix removal of unneeded startup/shutdown scripts Honor network type and link from lxc-create -f Add distro config file /etc/lxc/lxc.conf Add distro config file /etc/lxc/lxc.conf Reinstate README file in rootfs directory Fix package name needed for building docs with RPM Fix checkconfig to handle kernel memory cgroup name change Fix fd leak in lxc log Fix use of list item memory after free Free allocated configuration memory Ensure argv passed by createl to create is NULL terminated Use autoconf LXCPATH instead of hardcoded LXCDIR Make config api items const Oracle template: make container also boot under libvirt Fix busybox template to not have extra aa_profile hunk Fix build with --enable-tests on Fedora Include lxc-ubuntu when doing make dist Create busybox commands as symlinks instead of hardlinks make install should create $LXCPATH directory Use LXCPATH and LOCALSTATEDIR instead of hardcoded /var make install should create /var/cache/lxc directory lxc.spec: add openssl and rsync as Required since both are used in lxc-clone assume LXCPATH took on default localstatedir based value in configure Frank Scholten (1): Updated README and INSTALL. autogen.sh command should be run before configure. Frederic Crozat (1): ensure btrfs subvolume is removed when container creating fails Jan Kiszka (2): lxc-wait: Add timeout option Add network-down script Natanael Copa (9): lxc-start: add option -p, --pidfile=FILE lxc-create: use posix shell instead of bash lxc-create: fix passing over first argument to template script lxc-create: do not use 'local' lxc-info: add option -t, --state-is=STATE to test for a given test lxc-version: use POSIX shell instead of bash lxc-checkconfig: use POSIX shell instead of bash lxc-setcap: use POSIX shell instead of bash lxc-setuid: use POSIX shell instead of bash Peter Simons (2): Update documentation to Docbook 4.5 Update documentation to Docbook 4.5 Serge Hallyn (39): Introduce support for seccomp. confile: support 'lxc.include' option to include other config files seccomp: include lxcse
