[lxc-devel] [PATCH] have systemd service call lxc-autostart via script

[Michael H. Warfield]

On Thu, 2014-05-01 at 17:57 -0400, Stéphane Graber wrote:
> On Thu, May 01, 2014 at 05:51:15PM -0400, Michael H. Warfield wrote:
> > On Thu, 2014-05-01 at 17:31 -0400, Stéphane Graber wrote:
> > > On Thu, May 01, 2014 at 05:14:12PM -0400, Michael H. Warfield wrote:
> > > > Related to this...  Dwight and I have been bouncing a couple of things
> > > > back and forth and I noticed that lxc-autostart is being called from the
> > > > sysvinit scripts without the -a parameter.  That means that any
> > > > container in a non-null group will not be autostart on boot.  I feel
> > > > that's the wrong behavior.  If autoboot = 1 then it should be autobooted
> > > > on boot.  What you do after boot is up to you but I would expect it to
> > > > be "autoboot = 1" => "autobooted on bootup", not "autoboot = 1" =>
> > > > "autobooted on bootup if it's not in a group".
> > 
> > > I can see why you'd auto-start both the null group and say a "boot"
> > > group, but I don't think we should auto-start them all.
> > 
> > OTOH, I wanted to group my services "WittsEnd", "WittsEnd-DNS",
> > "WittsEnd-Web", "WittsEnd-DB" so they could be filtered and managed as
> > groups but I want them all to start at boot, maybe by groups (boot the
> > DNS first and then the DB and then the Web).  I would control if they
> > autoboot at boot time with the autoboot parameter.  The order grouping
> > can be handled now with some of the other options but, if autoboot does
> > not mean we autoboot the container then we chose the wrong name for the
> > parameter.
> > 
> > Perhaps we need a parameter in /etc/lxc/lxc.conf that can specify what
> > groups to boot at boot time?  The fact that this is not parameterized,
> > it works in a way that forces me to modify the system scripts with is
> > (cough) suboptimal.  Alternatively, if a container could belong to
> > multiple groups, say "WittsEnd-DB,boot" then anything belonging to the
> > boot group would autoboot at boot (I'm sounding like I have a stutter
> > now) would then autoboot.
> > 
> > > A reason is that I use those groups as a way to easily start a group of
> > > interdependent containers, when I need those, I do "lxc-autostart -g
> > > blah" and all containers that have lxc.group = blah and lxc.start.auto =
> > > 1 will start properly sorted, with the right delays, ...). I however
> > > don't necessarily want those to start at boot.
> > 
> > That's fine for you but it's not how I need them to work in a production
> > environment when I reboot the iron.  What you do after the iron is up is
> > not an "autoboot" condition but one where you are boot and controlling
> > groups.  A friend of mine has "ByTheSea" and my son has "Malamaber" on
> > my colo iron.  Using groups is great for me to shut down all the
> > "Malamber" containers collectively but I want all of them coming up if I
> > flip the BRS (Big Red Switch) on the iron.
> > 
> > I've suggested two options above that could accommodate both paradigms.
> > Parameter in /etc/lxc/lxc.conf or multiple group memberships.  Thoughts?
> 
> Multiple group memberships is already supported, lxc.group is stored as
> a list so you could do as I suggested in my previous e-mail and have the
> init script call ("lxc-autostart && lxc-autostart -g boot") then have
> the containers you want to start at boot time have the lxc.group = boot
> on top of any existing lxc.group they may already have.

> Support for a list of groups to auto-start in /etc/lxc/lxc.conf was also
> part of the original specification, however this hasn't been implemented
> yet, mostly because the parser for lxc.conf is rather minimal and it
> seemed to much of a pain at the time :)

Well, wait a minute.  Maybe it is and maybe it isn't.  What if that
parameter was a direct analog of the -g parameter?  IOW, you don't allow
multiple instantiations but just have a single parameter with a comma
separated list just like you have with -g?  That seems pretty simple.
Just malloc a string and store it.  You've already go the run-time
parser chopping up that csv string from the -g parameter (which would
obviously override).

> Regardless, patches are welcome for that bit :)

I may look at this.

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!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140501/09ca7951/attachment.sig>