[lxc-devel] making lxcpath a real path?

[Stéphane Graber]

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: ?).

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.

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



> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk

> _______________________________________________
> Lxc-devel mailing list
> Lxc-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel


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