[lxc-devel] utsname might not be enough, add optional containername?

[Daniel Lezcano]

Michael Holzt wrote:
>> I suggest adding a containername variable,
> 
> Ok, i was missing that it uses the name on the commandline for cgroup etc.
> and not the utsname. Sorry for that.
> 
> This however is somewhat in connect with my proposal regarding lxc-start etc.
> 
> I'm used to xen and as i already told, on xen i just say "xm create <name>".
> "name" is actually not the name of the domain but the name of a configfile.
> xen will then do everything as specified by the configfile. xen will take
> the actual name of the instance out of this configfile, so i can for example
> copy mydomain.conf into mydomain.conf.test and use this configfile, but 
> still have the name of the instance be "mydomain" as specified in the 
> conffile.
> 
> I really like this approach much more than the current approach in lxc.
> Now as i was told today (obviously missed that before) it is possible to
> supply the conf-name by parameter to lxc-start, so i can at least get rid
> of the lxc-create invocation. But still i need to supply the name of the
> container on the command line as well.
> 
> What also bugs me about lxc is that i always have to write -n before the
> name of the container. This seems unnecessary. Bad enough, lxc-ps does not
> even know "-n" and must be used with "--name".

Yep, lxc-ps and lxc-netstat can be improved.

> Considering all this, i propose to put the containername into the config
> file and allow e.g. 'lxc-start -f conffile' or even better 'lxc-start
> conffile'.

No problem for adding the container name in the configuration file but
we should be able to start something different than '/sbin/init'.
I am favorable for adding the command to launch in the configuration 
file too. But we have to keep the options in the command line because we 
should be able to start a simple container without configuration file.

> Also i would like to see other commands simplified. There is no need for
> 'lxc-netstat -n container', just make it 'lxc-netstat container'. Other
> candidates: 'lxc-ps container', 'lxc-cgroup container ...', etc.

That makes sense but I prefer to not change the command line for the 
moment as we have some tools using this syntax for a big project.

The lxc tools should allow to run something different than a system in a 
container, for example an application. This is very important for the 
next steps of lxc, I mean the checkpoint / restart / migration. Because 
we won't be able to checkpoint everything at the beginning (eg a full 
system) but only applications like sshd. Furthermore, people will be 
interested by containers for different reasons. For example someone may 
be interested by the checkpoint / restart only and will want minimum 
isolation.

What do you think if we use a wrapper around the lxc commands called "lxc" ?

The "lxc" command is:

	lxc <command> <options>

And it calls the different lxc-<commands> with the right parameters.

lxc create <container> <conf> or lxc create <conf> (to be defined)
lxc destroy <container> <options>
lxc start <container> <options>
lxc netstat <container> <options>
etc ...

This is very similar with what does git, a single command in /usr/bin 
and sub-commands stored somewhere else not in the exec path (on opensuse 
  it's /usr/lib64/git/git-*).