[lxc-devel] [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and systemd.
Stéphane Graber
stgraber at ubuntu.com
Wed Oct 1 18:18:27 UTC 2014
On Wed, Oct 01, 2014 at 12:41:26PM -0400, Michael H. Warfield wrote:
> On Wed, 2014-10-01 at 12:06 -0400, Stéphane Graber wrote:
> > On Wed, Oct 01, 2014 at 11:51:47AM -0400, Michael H. Warfield wrote:
> > > On Wed, 2014-10-01 at 11:34 -0400, Stéphane Graber wrote:
> > >
> > > [snip]
> > >
> > > > > Would this be better if this paralleled autodev an we only disabled kmsg
> > > > > by default if and when systemd was detected as the init system? The
> > > > > situation is very analogous to the autodev situation. If a user were to
> > > > > switch from say upstart to systemd and autodev is not specified in the
> > > > > config, we default that to enabled when we detect systemd as the init
> > > > > system at run time. We could also default kmsg to 0 in the case of
> > > > > systemd being the run time init system manager to prevent journald from
> > > > > going into it's console message loop and burning CPU. Would that work
> > > > > better for you? Since you can switch init systems from within the
> > > > > container and may not have access to the container config file that's in
> > > > > the host, something should be done to cover the run time case, like we
> > > > > do with autodev. That's what I was attempting to do...
> > >
> > > > I'm not very much fond of having to do per-init system config changes
> > > > but yeah, that sounds like a reasonable way to go.
> > >
> > > > If we start getting more and more of those cases we may want to make
> > > > things slightly more configurable by just having LXC include some
> > > > default configuration files based on that detection.
> > >
> > > Oh? Sort of like conditional includes? If lxc.init = systemd include
> > > systemd.conf sort of thing? It would have to be runtime conditional but
> > > that does make some sense at that.
>
> > So I see a few ways of doing it:
> > 0) We keep all the logic hardcoded as it is today for autodev.
>
> > 1) We keep your detection code and simply call
> > load_config("/usr/share/lxc/config/<init-system>.conf") before parsing
> > anything else, so the container's own config will override anything
> > that's in there.
>
> > 2) We make our parser support conditionals and export init_system as a
> > variable so that we can have the default distro configs do things like:
> > [init_system==systemd] lxc.include = /usr/share/lxc/config/systemd.common.conf
> > [privileged==false] lxc.include = /usr/share/lxc/config/unpriv.common.conf
>
> > This would be more flexible and allow for the addition of extra
> > variables later on. It'd also allow switching between privileged and
> > unprivileged and between init systems without configuration changes.
>
> > 3) We do a slightly simpler version of the above by adding two things:
> > - Simple variables, like ${init_system} and ${runtime_mode} and
> > allow using them in the config with the parser replacing them with the
> > right thing at parsing time.
> > - Add a @ keyword which when placed at the beginning of the line
> > will tell the parser to ignore any failure caused by the line in
> > question.
>
> > This then allows us to put things like:
> > @lxc.include = /usr/share/lxc/config/ubuntu.${init_system}.conf
> > @lxc.include = /usr/share/lxc/config/ubuntu.${runtime_mode}.conf
>
> > And not have the parser fail if I somehow decide to run OpenRC as my
> > container's init system without an existing ubuntu.openrc.conf.
>
> Ok... Option 0 is just about recoded so that the default kmsg is
> dependent on systemd and not merely autodev. I've turned
> "check_autodev" into "check_systemd" and conditionalized both autodev
> and kmsg based on that return value, dependent on any explicitly set
> value. For the short term, that appears to be the quickest and easiest.
>
> Option 3 sounds like a good versatile long term option but we still need
> some runtime autodetection of some of those values. Where does that
> ${init_system} come from? Since container owners can internally change
> their run-time configuration to switch init system manager and then
> reboot the container, something needs to be detected at runtime or the
> container could end up being configured in ways that degrade the
> performance or behavior of the host. Even then, we still might have a
> gap in the reboot process if the configuration is not reevaluated when
> the container is rebooted (aot shut down and restarted).
>
> Not sure if I care that much for option #1. #2 would be my second
> choice for a long term strategy with the proviso that we have some sort
> of runtime detection.
There would be a list of variables which LXC exposes to the config
parser, so LXC would still do the init system detection as it does
today, though possibly add detection for a few more init systems and
then set init_system accordingly before passing it to the parser. Same
goes for runtime_mode, LXC would set this to "unprivileged" or
"privileged" based on the usual userns check we have internally.
>
> Regards,
> Mike
>
> > > > > This bug is now closed, after I explained to the originator what the
> > > > > problem was, but it points out the problem we're seeing from having kmsg
> > > > > being a symlink to console and having journald run crazy in the
> > > > > container...
> > > > >
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1141456
> > > > >
> > > > > --
> > > > >
> > > > > > (1) Starting a basic LXC container, which is not configured to do anything at all, *immediately* (and without delay) raises the temperature *substantially* of one of the cores.
> > > > > >
> > > > > > (2) Starting a second LXC container (also not configured to do anything), does the same as (1), but on a different core (i.e. the one that that LXC uses).
> > > > > --
> > > > >
> > >
> > > [Big snip - this time I remembered...]
> > >
> > > Regards,
> > > Mike
> > > --
> > > Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at 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!
> > >
> >
> >
> >
> > > _______________________________________________
> > > lxc-devel mailing list
> > > lxc-devel at lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-devel
> >
> >
> > _______________________________________________
> > lxc-devel mailing list
> > lxc-devel at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
>
> --
> Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at 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!
>
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20141001/d14c30b7/attachment.sig>
More information about the lxc-devel
mailing list