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

[Andrian Nord]

On Sat, Jan 09, 2010 at 09:13:13AM +0100, Michael Holzt wrote:
> > Does is mean the purpose of these three patches, is only
> > to have the -n/--name parameter to not be mandatory for
> > the lxc-start command ? and be able to place it in the rcfile ?
> 
> Yes, that is the purpose and in my opinion the right thing to do.
> It should absolutely be possible to start a container with only
> providing a rcfile. Xen does is that way, and i believe openvz and
> vserver as well. This allows e.g. to create a /etc/init.d/lxc-container
> which on start can loop through /etc/lxc/auto/*conf and start all
> containers. This would also be possible by deriving the container 
> name from the file name, but that is a ugly hack in my opinion. 
> 
> Please note that my patch maintains old behaviour and still allows to
> specify the container name on the command line. But this patch is
> the smaller solution to my aim to make the lxc commands easier to 
> use and handle. 

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

For me, that's just logically incorrect:
1) Name is container identifier, just like veid in openvz. Config is holder
of configuration values and potentially one config could be shared by
enumerous value of containers. So config could not (and, imho, should
not) be used as identifier.

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>? This is, at least, strange. Or it would be mix
of different logic - lxc-start will accept config as identifier, while
other utilities will not. So your scripts would be forced to parse
config files to get name from them to use in lxc-stop or whatever they
need. And what would happen if some files has name and some has not?
That will to complete mess and chaos, imo.

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

> 
> I outlined my rationale the other day in my mail and Daniel replied with
> "No problem for adding the container name in the configuration file", so
> i did that. As suggested by Daniel and ack'd by me the goal is to have
> a "lxc" executable which will invoke the lxc-* commands and to keep that
> tool as simple as intended, i needed lxc-start to be able to start with
> only the config file, which is also enough.

git-like interface would be great, I was thinking a lot about such possibility,
and I don't see, how this task depends on ability on start with
config file only. As I've stated above, your idea, imo, will make things
even worse.

As I see this: you should use one-and-only-true identifier, obviously
it's name, see above. And, probably, you could use it for searching for
config file, if you don't like default behaviour. What about starting
with init.d - there is three different type of configs:
1) "configfull" - containers has their own configs, shared with
nothing else.
2) "config-shared" - many containers sharing fewer ammount of configs
3) "configless" - containers (application-containers) that do not
require any configs (for running applications into safe sandbox, for
example)

As you see, there is no way basing on configs anyhow if you want to
cover with your init.d all this possible configurations. Better idea,
imo, whould be using (keeping traditional for Gentoo baselayout syntax):

lxc="<containername1> <containername2> <containername3> ..."

<containername>_config="/path/to/config file"
# default is LXCPATH/<containername>{.conf,/config} whatever your like
# most. Probably user-configurable.

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.