[lxc-devel] Q: general lxc architecture

[Daniel Lezcano]

Andrian Nord wrote:
> On Wed, Nov 11, 2009 at 09:30:27PM +0100, Daniel Lezcano wrote:
>> What I have in mind is to just copy the file somewhere with lxc-create 
>> and remove it with lxc-destroy. And, much more later, integrate in a 
>> nicer way lxc-debian, lxc-sshd, lxc-fedora, lxc-busybox, etc ...
> 
> Yes, I got it, but I was about source for copying, i.e.
> /etc/lxc/template.conf or, maybe, /usr/share/lxc/template/, etc - you
> plan to do it on some hardcoded path (say /usr/share/lxc/template), or,
> maybe, concept of global /etc/lxc.conf (with option
> lxc.create.template = /usr/share/lxc/template) would be introduced
> 
> But this is not so important, anyway, but, still, global config might be
> useful for certain things.

Ah ok, I understand. Yes, may be this is good idea to dig. Someone told 
me it would interesting to add a 'lxc-clone' command to copy the 
configuration and I has certainly in mind more tricky things like 
copying the rootfs, etc ...

>> Not exactly.
>>
>> 1) You created the container before, lxc-start/lxc-execute use the 
>> configuration.
>> 2) You didn't create the container before, lxc-start/lxc-execute use the 
>> configuration file specified in the command line (if none specified, 
>> then default values).
>>
>> eg.  lxc-start/lxc-execute -f <config> -n mycontainer -- /bin/bash
>>
>> At present, this is what happens more or less because when you call 
>> lxc-execute and the container does not exist, it is created before and 
>> destroyed after. In case of failure, (machine crash, lxc bug, kill -9), 
>> the container is not destroyed.
>>
>> And I think it is much more simple to keep a single generic 
>> configuration to pass it to several lxc-start/lxc-execute instead of 
>> creating them before. But that do not prevent the create the containers 
>> before to keep a persistent configuration for a specific container. Both 
>> behavior are kept.
> 
> Yes, yes, I got the primary idea, but... You mean, that I could have
> different configs for temporary containers (read - autochroot), but I
> may have single rootfs? But it's value controlled by lxc.rootfs
> option, so it may be done at present.
> 
> But if you intend a fallback-config pattern like 'if container is
> persistent, than read it's config, otherwise read specified fallback-config',
> how could I change some configuration values to make my containers
> different in, say, network ip, or utsname?
> 
> This seems to be usable only for network-less containers, or containers
> that can share exactly same roots - i.e. for isolating/limiting specific
> tasks. Autochroot - again. But, as it seems for me, it might became slightly
> more usable, if there whould be an additional option, like
> 
> lxc-execute --define lxc.network.ipv4=192.168.1.2/24 -f <config> -n ...

I am not sure to get the idea. Do you mean, you would like to override 
some options in the configuration file by passing long parameters to the 
command in order to keep a single configuration file ?

> In that way it could be used for spawning isolated networked applications
> or small full-featured temporary containers sharing most of fs (via ro
> binds), but having small exclusive amount of diskspace (or ramspace via
> tmpfs). This could be used for providing save-and-cheap dynamically
> spawned and cleaned full featured demo-environments for, say, educational
> purposes. I.e. it could be used as terminal server, for example.
> 
>> Aha, good point ! To be fixed :)
> 
> I'm using lxc for one-and-half servers (participating in configuring
> of second one), and I've got a few ideas how it could be improved in
> different ways. I'm planning to implement them as I would have some more
> free time, but may I previously post them here (as another thread), maybe
> you have some additional ideas or another design view?
> 
>> Oops, you moved a wrong one :)
> 
> What do you mean? Are you about garbaged patch? I don't know why it
> happens =) Should I attach patch?
> 
> Or you are about what it does?.. Or something else?
> 
> I'm sorry for requestioning, I hardly understand short phrases without
> context (due to just too big variety of possible translations)

No problem, my bad I was not clear :) I just meant you moved the 
lxc-complex-config file which is a generated file from the .in

Anyway, I fixed it. Thanks.

   -- Daniel