Quoting Jäkel, Guido (g.jae...@dnb.de):
> Hi Serge,
>
> >> to assist to avoid such problems i would propose to introduce macro
> >> expansion (of the own tags but also by incorporating the
> >environment variables) into the configuration argument parser and to provide
> >some useful basics like the container name. Then one may
> >use e.g.
> >>
> >> lxc.hook.mount = $MYCONTAINER_HOME/hooks/$lxc.name
> >
> >That sounds good. Would you be able to post a patch to do this?
Ok, so along the lines of this, I propose (and will send a patch soon
if there are no objections) the following behavior for lxc-clone:
1. hook files only get copied if they are in $lxpath/$lxc_name
2. hook files do not get 'updated'. They should be using the
container name and lxcpath from environment/arguments
3. configuration file will expand $p to lxcpath and $n to
lxcname (with \$ for escaping $ though I can't see anyone
doing that).
4. $lxcpath/$lxcname/fstab and lxc.mount.entries should not
need to be updated. The destination should be relative to
the mounted container root. I don't know of any cases where
the source is relative to the container itself. If there are
such cases, then we can add $p and $n expansion to ONLY the
mount source.
5. lxc_clone will update the container name in lxc.utsname only.
-serge
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
