[lxc-devel] making lxcpath a real path?
Michael H. Warfield
mhw at WittsEnd.com
Tue Dec 3 22:35:29 UTC 2013
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 | 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!
> >
>
>
>
> ------------------------------------------------------------------------------
> 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
--
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/acef32e1/attachment.pgp>
More information about the lxc-devel
mailing list