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 | m...@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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
