[lxc-devel] LXC Autostart and order...

[Michael H. Warfield]

On Wed, 2014-05-14 at 13:19 +0000, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > This is more directed at Stéphane but other thoughts and comments are
> > welcome.
> > 
> > I'm also looking at the lxc-autostart code and I've noticed a couple of
> > things...
> > 
> > The -g / --groups option is only a single instance option.  Should this
> > allow for multiple options?  i.e.  "-g ,onboot -g Mygroup"  Right now,
> > it looks like last one wins.

> Yes, supporting multiple options is a desired feature, I think Stéphane
> had said that if you want to pursue a patch to do that that'd be great.

Yeah, I got his message so I'm on it.  I'm a little out of pocket today
but may have something by the end of the week.

> > That could be handled just by appending multiple instances, separated by
> > commas, when processing the command line, even though we later break the
> > list apart into a list.
> > 
> > It looks like the sort ordering is not taking into account group
> > membership.  It goes through the list of containers ordered by the
> > lxc.start.order parameter and sorts them without regard to what groups
> > may have been specified.  That means that "onboot,myboot" is the same as
> > "myboot,onboot" and that "WittsEnd-web,WittsEnd-DNS" is the same as
> > "WittsEnd-DNS,Wittsend.web".
> > 
> > So the -g option is then order independent for the specified groups.  Is
> > that our desired behavior?  If so, that should be documented or there

> I suspect it is, then if you want one group started before the other you
> can just call lxc-autostart multiple times.

Yes, but we would need to then document that and the current behavior or
it would be confusing.

> > may be some undesirable results if dependencies fail.  That gives me
> > some heartburn that we may need to document that you need to group your
> > orderings to insure that members of one group do not get started before
> > members of other groups.  Just doesn't feel like a clean paradigm there.

> It could be more flexible than always starting them in the group order.

Since multiple group membership is permitted, I think they're about
equally flexible with multiple invocations in the current case, which
was what we were trying to avoid.

> Although I guess actually I prefer going the other way:  allow containers
> to be associated with multiple groups, and only allow one group name to
> be specified with lxc-autostart.  Then if you want groups x1 and x2 started
> at the same time, you just add all x1 and x2 containers to group y1 as well
> and start that group.

We can already specify multiple groups to lxc-autostart so that would be
taking away functionality.

> That seems simpler to think about, but as I'm not one of the power users
> here I'll defer to Stéphane and yourself.

Cool.

> > It's that loop that runs through the containers after the qsort and then
> > queries lists_contain_common_entry() that's doing that.  That's where
> > adding a catch for the NULL group may be a challenge.  Special case
> > where there's a empty string in the group list and no membership in any
> > group in the lists_contain_common_entry() would catch that.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
ARIN whois: ARIN-MHW9       | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!