[lxc-devel] making lxcpath a real path?

[Michael H. Warfield]

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

> ?

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!

-------------- 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/b5c1f860/attachment.pgp>