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

[Daniel Lezcano]

Andrian Nord wrote:
> 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.
>   
Well, this can be interesting, but we must avoid overkill features, so 
that need some clear semantics.

You and Michael have a lot of good ideas and I suggest to store these 
ideas in the "features request" / lxc category:

https://sourceforge.net/tracker/?group_id=163076&atid=826306

> 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?) 

I would like to release a 0.6.4 version before taking more patches.

> 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?
>   
Do you mean override the LXCPATH with an environment variable ?