[lxc-devel] making lxcpath a real path?

Tue Dec 3 16:04:31 UTC 2013

On Tue, Dec 03, 2013 at 10:57:44AM -0500, Michael H. Warfield wrote:
> 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).

Sure, I never said that using : as a delimiter wasn't common for some
specific cases (mostly path environment variables) but it's not
consistent with what we've been doing in LXC and until now we've been
fortunate enough not to have to add extended parsing for paths in our
code and I'd prefer for it to stay that way.

> 
> > 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.

My expectation for the userns work was that we'd define a default
lxcpath for when LXC is ran as non-root and an alternate location for
lxc.conf too. So the user could simply set lxcpath in say
.config/lxc/lxc.conf and all commands would respect that (just as they
all respect /etc/lxc/lxc.conf at the moment).

> > > 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!
> 

-- 
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: 836 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20131203/4d1a3bd6/attachment.pgp>