[lxc-devel] current git: lxc-start now requires -f ?

Michael Tokarev mjt at tls.msk.ru
Mon Nov 16 13:04:05 UTC 2009


Andrian Nord wrote:
> On Mon, Nov 16, 2009 at 12:17:16PM +0300, Michael Tokarev wrote:
>> You mean mount, for 'lxc.mount' keyword?  As I mentioned before, that
>> keyword has been extended recently (take a look at current git and at
>> recent lxc-devel archives), to not require separate mount file anymore
>> and specify lxc.mount.entry in-line in the container config file.
> 
> lxc.mount.entry exists for using in scripts, it not replaces lxc.mount
> (it can't, due to limitations of mntent.h API). For me it's much
> simplier to use fstab syntax as fstab file - at least it will be
> highlighted =)

lxc.mount.entry *does* use fstab syntax _and_ use mntent.h API.

lxc.mount.entry = /dev dev none bind 0 0
lxc.mount.entry = /dev/md8p2 stage ext3 defaults 0 0

It _aims_ to replace lxc.mount, in order to keep all configuration
in a single file.  For now the two co-exists, and I see no reason
to remove lxc.mount entirely either.

I see no specifics in "for using in scripts".  Every usage is ok
as far as it makes sense, there's no difference in API for one
usage or another.
[]
> If you have changed your configs following new behaviour so fast, ok,
> but probably I should not count on that ;)

I didn't change anything.  More, I don't really _have_ anything yet, I'm
just testing/evaluating things in a hope to produce something that'll work.

>> That's why I didn't sent some similar patch in my first email: writing
>> code isn't that difficult, but thinking about how it will work and how
>> whole thing works, to have clean and logical interface and structure,
>> is much more difficult.
> 
> It will work very simple - as before - if you specified any config - it
> will use it, if not - it will read 'default' one or fail.

But the thing is that default changed.  It were defaulting to /var/lib/lxc
before.  It wasn't a config per se, or at least not the original config.

The point is, before the changes in question, only necessary thing was to
specify -n, the rest (all other config stuff) were read from
/var/lib/lxc/$name/config and other files in that directory.  That worked,
and I guess several people have it working this way.

Now, provided no -f option is given (as it used to be in 0.6.3), it either
does not read anything (without this your patch), or reads /etc/lxc/something.
In neither case any old setup works.

>> Besides, your patch will break withOUT config: it does not check if
>> /etc/lxc/$name/config exists.
> 
> Ah, yes, I've forgoten about configless containers. Really, I don't see
> much sense in them, but ok...

This is what I'm talking about really.  Writing code is simple, but thinking
is not.  I'm not about config-less containers but about a way to preserve
previously working setup somehow.  And before writing code I'd want to
discuss where we will go from here.  For example:

  1) drop /var/lib/lxc/ entirely
   1a) and provide some tool that will move configs from that dir to /etc/lxc
   1b) and warn user that his setup is now broken and that he should inspect
    and move things manually, provided that his _original_ configs were not
    in /etc/lxc/ already and so on.
  2) continue using /var/lib/lxc/$name/config as a default config location,
   at least for some transition/historic period

This is for currently used config-like structure.

Besides, we should think how we want to configure things in the future.
Many different ways makes little sence, including your foo.conf and foo/config
or even plain foo choice.  If one makes more sense than another pick it, but
don't pick both as it adds confusion.  That's a question about where we want
to go from here.

Personally I'd go for 1b since tools are not very old and we've not many users,
and most usages are really experimental for now.

As for the direction to move, I'd go for /etc/lxc/$name.conf or even
/etc/lxc/containers/$name.conf.  Subdir makes sense because I bet there will
be some common scripts - for example to start/stop things or configure
networking (maye /etc/lxc/scripts/ is ok too), and there should be a place
to provide a list of containers to start at boot (like /etc/lxc/auto/
with symlinks to /etc/lxc/container/*). Alternative to subdirs (besides
/etc/lxc/auto/) is the .conf suffix.  Ok, /etc/lxc/$name.conf is probably
the best choice still.

Thanks!

/mjt




More information about the lxc-devel mailing list