[lxc-devel] versioning the container monitor api
Serge Hallyn
serge.hallyn at ubuntu.com
Tue Aug 27 18:59:20 UTC 2013
Hi,
One of the issues we want addressed for lxc 1.0 is versioning. There
are a few pieces to that:
1. liblxc itself should be properly versioned
2. the hook exports should probably versioned so that consumers
of say the lua hooks know what they are dealing with
3. the internal monitor should be versioned
I intend to discuss 1 and 2 at plumbers, however I thought I'd float
3 on the list now. An example of the bad things that can happen:
I start a container running a crucial mail server. I upgrade
lxc. The new lxc has changed the format of messages for the
commands api. Now I do 'lxc-list', which queries the running
monitor to check its init pid with LXC_CMD_GET_INIT_PID. The
container monitor crashes on bad input.
The lxc_af_unix_connect function could start with a handshake with a
version number, or we could tack a version # onto the lxc_cmd_req
struct. Best would be if we agreed the client always sends its version
to the monitor, then vice versa, and then both sides decide whether
they can proceed (so both sides can log error). We could just use
a monotonically increasing int, hand-inserted. However that's subject
to error - if we make a change without remembering to update the version
number, then we could still get a crash. We could automate this perhaps
by having a Makefile do some sort of check, i.e. hashing all the structs
which may be communicated over the socket.
There is also the question of how best to handle changes - I think it's best if
we just reject any connections between different versions, recommending to
users that they log in and gracefully shut down the container. But we might
want to try and accomodate newer clients talking to older versions, somehow. I
suspect that'd be fragile, but it might be worthwhile.
Has anyone had thoughts on this?
-serge
More information about the lxc-devel
mailing list