[lxc-devel] [patch 1/1] fix container find the previously created configuration

Andrian Nord nightnord at gmail.com
Tue Nov 17 22:08:34 UTC 2009


On Tue, Nov 17, 2009 at 10:30:33PM +0100, Daniel Lezcano wrote:
> Right, just the difference between debian and fedora is enough for me :)
> I hope in the future, we can do some templates scripts to be called from
> the lxc-create command.

I'm really happy with cp -a, for Gentoo this is most flexible and usable way,
but I can't speak of other distros, I don't know =)


> Yes, that is the idea behind the lxc-info command. Michel suggested a
> good idea: at startup the lxc-start process does a private memory
> mapping of the configuration file, so it is accessible and unmodified
> even if the user modify or delete it. The lxc-info pass a file
> descriptor via the af_unix socket to lxc-start, and this one simply
> write the content of the memory mapped file to the file descriptor.

Em. Yes, idea is good, but why we may need an raw config file, when we
already have full-filled lxc_conf structure? Of course, dumping lxc_conf
to human readable way (say into config format) is much more complex
task, but...

If some command, say lxc-config, would be capable of fetching arbitrary
configuration from container, running or not (if not started - by offline
configs parsing), and setting arbitrary configuration entry - it would
be great utility for maintaining containers. First of all, it would allow
to runtime change of some configuration parameter (changing mounts require
insider into container, I'm trying to implement this for lxc-init). Also
it will give us opportunity of fetching and presenting more usable
information about container, that just it's state - it would be great
for scripting and for any high-level frontends. It even would allow to
build really simple web-interface.

Why this is harder to implement if you will keep raw config (you can
always grep it, for example) - because, if my patches about variables
and config.include (any news about them, by the way?) Would be applied
(IMO this is right direction of distributing configuration, extracting
all common options into some common config), this would be somehow
harder - how many of configs you would keep in memory with all comments
(if someone love comments, it could be valuable amount of memory. If
you will have 5000 of containers - even more valuable ;))? Also, how you
will track variable changes (i'm planning to extend variables support to allow
arbitrary variables - I just need some minimal perfect hash algorithm
(it would be useful and for other configuration parts))?

It will force you to reparse all sequence of one config update - this is not
a way to go, really.

But, anyway, offline config retrieval, in any implementation, would
need some assumption, where this config is kept.

> One option maybe to use the environment variables to define the 
> configuration. So the user can source the common configuration and then 
> the specific configuration and run the container.
> 
> At the final, the container can be configured with:
>   * a create [ + a configuration file ]
>   * a -f option
>   * the environment variables
> 
> The -f overrides the configuration of the created container, the 
> environment overrides the -f.
> 
> That let you to do whatever you need IMO, no ?

*sigh* It's enough '-f' for me, really, env vars would be redundant, imo.

Still, it gives me an idea - what if there would some environment
variable, that specifies format for asprintf used for making 'default'
config path? User would be able to use such env variable in his .bashrc
or similar, with two '%s' in string, first for LXCPATH, second for
container name (or just one, only for container - he knows where his
configs lies), efficiently changing default container's configuration
layout assumption.

What would you say about that?




More information about the lxc-devel mailing list