On Tue, 2013-12-03 at 11:04 -0500, Stéphane Graber wrote: > 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. The parsing, in and of itself, is not complicated and very deterministic. I've done these kinds of things before. And it would be compatible with your suggestion of multiple -P options. You have an internal and an external representation. The internal representation would be a straight correspondence to your multiple -P case and would just be an array of pointers. In that way, the internal representation would be both external (command line multiple -P) and internal. But... That's not real compatible with environment variables. I was just looking at the environment variables we provide to hook scripts. I was really surprised that, in spite of the fact that we provide LXC_NAME, LXC_ROOTFS_PATH, LXC_ROOTFS_MOUNT, and LXC_CONFIG_FILE, we don't provide LXC_PATH anywhere. That could potentially be very useful in a container hook and I'm surprised we missed providing it. If there was the possibility of multiple paths, providing it in an environment variable becomes problematical to say the least, unless it was in a parsable string (which is why things like PATH and LD_LIBRARY_PATH and others are structured that way). Other vendors (even Oracle and there proprietary stuff) use that standard convention. It works. Having the active (in use for that container) lxcpath in an environment variable would be useful for finding things like the devtmpfs stuff that's now been checked in so you could find the container dev directory readily at startup in the hooks. I'm less sure about the original "default" lxcpath (I got sidetracked by that function call briefly when working in that area until I figured out how to dig out the active lxcpath) or what value there may be in the multipath search path string, but I can see providing them in environment variables like this: LXC_DEFAULT_PATH LXC_PATH LXC_ACTIVE_PATH Where LXC_PATH could even be picked up out of the environment at startup time. All of the above is not at all complicated. What's complicated is tracking down all the references to lxcpath in the code and deciding what to do in choosing which path to use. That's true with either method. That's the difficult part. The parser and environment logic, I could knock out without breaking a sweat. If I did some parsing logic, would you look at it and consider it? I may do the additional environment variables for the hooks scripts anyways, just because I can see some immediate value there. Regards, Mike > > > 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 | 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! > > > > 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! > > > > > > ------------------------------------------------------------------------------ > 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 -- 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
------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
