[lxc-devel] [PATCH 3/3] Let lxc-start read container name from rcfile if not specified on command line

[Michael Holzt]

> And what whould happen if I'll specify name both in config and command
> line. What it will choose and why?

The one on the command line because it clearly has more priority.

> 2) Every lxc tool asks on what it should operate - obviously it should
> be container identifier. If it is config file than I should call
> lxc-stop <configfile>?

No. It should just be lxc-start which shall be able to act on a
config file only.

> 3) Also, what about ability to start container _without_ config file at
> all?

This is still possible. My patch just adds the possibility to add to
container name to the config file, but it can still be provided on the
command line and as said will take precendence.

> As I've stated above, your idea, imo, will make things
> even worse.

I don't see this. It just makes it possible to use lxc-start with a
rcfile which contains every needed configuration value. Nobody is
required to do so.

> As I see this: you should use one-and-only-true identifier, obviously
> it's name, see above.

I do.

> What about starting with init.d - there is three different type of 
> configs:
> 1) "configfull" - containers has their own configs, shared with
> nothing else.

This would be possible.

> 2) "config-shared" - many containers sharing fewer ammount of configs

So i have one rcfile in /etc/lxc/ and use this for many containers? This
would be confusing in terms of administration in my opinion. The beauty
of having /etc/lxc/auto/*.conf would be to be able to see with one ls
which containers are started automatically. So i really want to have one
config file for each container. The shared aspect might be better suited
by allowing to include another rcfile in the container specific one.

> 3) "configless" - containers (application-containers) that do not
> require any configs (for running applications into safe sandbox, for
> example)

A configless container has no config and can therefore obviously not be 
started by a generic init.d script which would not even know what to 
start. 

Also i wonder if such a container if of any use whatsoever. You call it
a safe sandbox, but is it? It protects from virtually nothing a malicious
user or binary can do in it, at least if one can get/hack root.

> As you see, there is no way basing on configs anyhow if you want to
> cover with your init.d all this possible configurations.

I beg to differ. It can be done and i think it would be for the better
anyway. Having (the possibility to put) as much as possible in a rcfile
is a good thing because it makes it much more simple to see the 
configuration of a container. Heck, we could even get rid of lxc-execute
and allow to specify the binary to execute in the rcfile. Which probably
makes sense in any case.

> Why? As user may not start every defined container on boot. As
> alternative solution - symlink lxc.<containername> to some common
> init.d, and checking $0 for container name could be used.

As i already proposed: Have /etc/lxc/auto. The conf files in there are
started automatically, the ones in /etc/lxc/ (or /etc/lxc/container
or what ever) do not. One can symlink or copy files into .../auto/.

I'm really -1000 to deriving a config value from a file name. This is
ugly and it will break at the worst possible moment. I want to be able
to cd /etc/lxc/auto ; cp ../domain1.conf ./test.conf ; edit test.conf ;
lxc-start test and have the domain started and still be "domain1" as
specified in the conffile.


Regards
Michael

-- 
It's an insane world, but i'm proud to be a part of it. -- Bill Hicks