[lxc-devel] making lxcpath a real path?

Tue Dec 3 15:57:44 UTC 2013

On Tue, 2013-12-03 at 10:20 -0500, Stéphane Graber wrote: 
> On Tue, Dec 03, 2013 at 10:00:02AM -0500, Michael H. Warfield wrote:
> > On Tue, 2013-12-03 at 12:49 +0100, Harald Dunkel wrote: 
> > > Hi folks,
> > 
> > > do you think it would be possible to make the path set by
> > > -P/--lxcpath or in the config file a _real_ path, e.g.
> > 
> > > 	lxc-ls -P /data1/lxc:/data2/lxc --fancy
> > 
> > > ?

> I'd recommend not using that kind of confusing syntax (e.g. what if I
> actually have a directory called /data/lxc: ?).

Well, there is plenty of precedence there with the syntax of various
PATH environment variables, syntax for NFS (and other) mounts, etc, etc.
That's a convention that has been embedded in *NIX that goes back
decades preceding even my involvement back in the '80s.  That, and you
can always escape a delimiter (doubling or \ conventions).  Colons are
considered reserved even to the extent that IPv6 literals, in many
cases, have to be enclosed in square brackets to indicate them.  In some
commands, the colon is used to delineate an address from a port number
even.  Using a colon in a file system path is already fraught with
gotcha's.

You can't have a directory in PATH or LD_LIBRARY_PATH with a ":" in as
part of the absolute path stanza although there are certain heuristics
that can be applied to allow it (a PATH stanza is and absolute path and
has to begin with a / so a :/ would indicate a delimiter and your
example may be coded as /data/lxc::/user/data for /data/lxc:
and /user/data say).

Arguing over ":" as a path delimiter, which is a long traditional
established practice, is on equal footing with arguing if someone should
be allowed to have a "/" in a file name.  The precedent has been set.

Which actually reminds me.  I did run into some cases where there was
some problem with whitespace in some names (an abominable, but common,
practice).  I won't totally swear that even the Fedora template will
handle white space in names and paths cleanly (I need to test that! - On
my list).

> Instead if we are to implement such a feature, we should be consistent
> with what we've been doing in the past and allow for "lxcpath" to be
> present multiple times in lxc.conf and for -P to be passed multiple
> times on the command line of all of our binaries.

Yeah, that's a convention that I personally never liked and is
inconsistent with so many other *NIX commands.  The two syntaxes are not
mutually exclusive, either, as each can easily be parsed into the other
in an unambiguous format using doubling as an escape (: -> ::) if you
really consider a ":" to be an important part of the filename namespace.
I could easily do some of the coding for that.  The uglier part would
actually be in the search logic wherever lxcpath is reference in the
code (which I just got done doing in some of my last few patches).

The multiple -P options also makes implementing some options and
environment variables extremely difficult and there may be some reason
for considering that.  Particularly, with what Serge is doing with user
specific containers, I could easily envision (and desire) an environment
variable LXC_PATH which could be set on a user basis in their profiles
and they could then use all the commands without repetitively adding the
-P option(s).  Ok...  Yeah, this could also be done with a crap load of
aliases as well but that's kinda butt ugly and, really, an environment
variable is cleaner and more appropriate to a case like that and a
search path makes more sense in that case.

> > You had me confused for a brief moment, referring to this as a "_real_
> > path" and I had to think about it for a bit.  We have a problem with
> > ambiguity in the language where "path" can mean multiple things.  It can
> > mean a singular absolute file system path to a file on a file system or
> > it can mean a delimited set of paths as in the PATH or LD_LIBRARY_PATH
> > environment variables.  Both are equally "_real_" it's the context of
> > the utilization that makes the difference.  One specifies a definitive
> > location while the other describes a "search path" to be processed.
> > You're suggesting changing the lxcpath from an "absolute path" to a
> > "search path" concept.  Interesting.  Intriguing.
> > 
> > But...  I see your point and it's an interesting idea.  It has
> > possibilities.  It also has the potential for ambiguous or confusing
> > behavior for some commands such as "lxc-start" or "lxc-create" where you
> > really want to specify a definitive location aot a search path (though,
> > I could see the use for a search for lxc-start (find the first stopped
> > container in a PATH stanza that's can be started - would that be safe?).
> > I guess lxc-create could settle on the first location it could write to
> > (placing user directories earlier in the path to control priority).
> > 
> > Worse would be the case of lxc-stop where there were multiple containers
> > with the same name only different lxcpath locations within the greater
> > search string.  That could get ugly and non-deterministic.  This could
> > certainly be beneficial to things like lxc-ls where containers are
> > scattered between different locations.
> > 
> > In that case, it might also be useful to utilize an LXC_PATH environment
> > variable in addition to the -P/--lxcpath command line options and config
> > file options.
> > 
> > That's a very interesting idea that I would support if we could work any
> > various ambiguous behaviors for all the commands in a way that did not
> > result in user confusion.
> > 
> > One thing I would NOT like to see is a situation where some commands
> > (lxc-ls) take a search path while some commands will only accept an
> > atomic absolute path.  That sort of confusion would not end well.
> > 
> > > This could help to support HA scenarios based on DRBD or
> > > a network file system, for example. If one LXC server
> > > dies, then a fallback host could take over the abandoned
> > > /data2/lxc in parallel to its own /data1/lxc directory.
> > 
> > > Regards
> > > Harri
> > 
> > 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!

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/20131203/407d6e6e/attachment.pgp>