[lxc-devel] suggestion for an autostart flag

[Michael H. Warfield]

On Wed, 2013-05-29 at 18:31 +0200, Harald Dunkel wrote: 
> Hi folks,

> AFAICS I have to list all containers to be started at boot
> time in /etc/lxc/auto using symlinks pointing to the
> config files. Problem: /etc is a local file system.

> For a HA solution you usually have some kind of "network"
> device/filesystem providing the resources to manage, e.g.
> a DRBD or iSCSI partition holding a set of LXC config files
> and rootfs directories. In case of a hardware failure you
> change the run level on a hot standby host, some init script
> mounts the LXC partition, and LXC's init script is supposed
> to start the containers for this run level. Unfortunately
> the symlinks in /etc/lxc/auto have been lost together with
> the old host. Hopefully you see the problem.

> Instead of symlinks in /etc/lxc/auto I would suggest to set
> the config files to executable as an autostart flag. Thats
> very easy to set, test and clear, _and_ it is part of the
> filesystem providing the LXC config file.

I would strongly disagree with this proposal for several reasons.

1) We have a proposal for a set of start parameters contained in the
configuration file itself which can handle this.

2) It's inappropriate (and often non-portable) to overload permission
bits for features for which they were not designed.  We just discussed
this wrt using the sticky bit for retaining the container run-state for
auto reboot state control. 

3) The file itself is not executable and using it in this way would
violate established file permission semantics.  Executing the file
would / should fail but it's an ugly failure and including the
conventional #!/.../lxc-start would not be a good solution.

4) There are potential side effects relating to selinux and/or apparmour
which would have to be explored (anytime you're playing silly buggers
with permissions).

5) It has none of the granularity of groups and priority (boot order)
that are provided for in other proposals.  It doesn't even provide for
the possibility of prioritized ordering through prefix in the symlinks
as as suggested by Serge ages ago when this was last brought up before
the current round or proposals.

> Just a suggestion, of course.

I think the current proposal for startup parameters contained in the
file will do what you want to do and in a way that can be transported
between systems, is portable between (differing) systems, and has a fine
grained control over boot ordering and grouping.

Please refer to the current thread in the list wrt "Container autostart
proposal V2".  If you haven't been / are not a subscriber (I saw the
moderation request come through saying you weren't), please check it out
in the archives and please join us for the discussion.  This is an
active discussion on the agenda.  You're very timely in that regard.

> Regards
> Harri

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  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!