[lxc-devel] Q: general lxc architecture

[Andrian Nord]

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.

> 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 ...

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)