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

[Daniel Lezcano]

Andrian Nord wrote:
> On Tue, Nov 17, 2009 at 11:07:59AM +0100, Daniel Lezcano wrote:
>> Right now, there is no more files other than the configuration file, 
>> LXCPATH/$name/config.
>> So I merged LXCPATH/$name and the config file, the $name is the 
>> configuration file.
>>
>> lxc-sshd and lxc-debian were changed to use the new option 
>> lxc.mount.entry, so these scripts don't have to generate an extra fstab 
>> file.
> 
> There is many distros, not only debian, and it's impossible to make utilities
> for easy creating and maintaining all possible distros, so, probably, it
> would be better to count on possibility of manual maintenance and
> creation ;)

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 wouldn't say 'bad' :), it adds more complexity around the 
>> configuration and we are trying to simplify it.
> 
> Yes, of course, but, imho, simply configuration doesn't mean 'dumb
> straightforward', when all configuration kept in single file and any
> batch change require a complex script. It's better to have distributed
> configuration, when it is _possible_ (read 'up to user') to extract configs
> for particular tasks to external file, while keeping them in one place
> (i.e. somehow grouped)

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.

By this way, at any time it is possible to retrieve the configuration
used by the container. I won't describe when the container is not
running as this is obvious :)

>> The other point is looking for different file format adds more overhead, 
>> I know it's ridiculous, but the door is open for adding more and more. I 
>> am planning to run 5000 containers on the same host, it will better to 
>> not look for what is the configuration file format :)
> 
> Yes, that's right (that's was what I was talking about, when I've
> mentioned speed, in discussion with Michael). But, if you will have 5000
> single configuration files (or configuration 5000 directories), it won't
> help =). If you are targeting on such systems, probably some mechanics
> of grouping and more flexible (but still fast) configuration layout
> should be chosen
> 
> For example it could be useful to have already mentioned global
> configuration file, where you will be able to specify where to look for
> specific configuration file. And, probably, batch mode operations should
> be introduced, i.e. starting/stopping many of containers at once/in
> threads with queue, without reloading all common resources every time ;)
> 
> But I really hope, that you are not targeting such huge-scale systems,
> at least until version 1.0 (there is libvirt + oVirt + freeIPA + ... for
> them already)

Yes, of course. I am planning to run 5000 containers (to check how the
containers scale), not manage them. I will let the system management to
handle that, this is not the job of lxc ;)

> Summarizing my opinion on this task: for me it's more preferable to let
> user choose how and where he would keep his configs, currently it's done
> by -f switch, of course, and, sure, I'll use it, still it's not perfect
> and, I'm sure, there could be some better design.
> Currently I have no particular ideas, but if I'll found one, sure, I'll
> inform you.

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 ?

Thanks
   -- Daniel