[lxc-devel] [PATCH] Add remove_snapshots_entry() (rebased - v2)

[Serge Hallyn]

Quoting Christian Brauner (christianvanbrauner at gmail.com):
> When creating ephemeral containers that have the option lxc.ephemeral = 1 set
> in their config, they will be destroyed on shutdown. As they are simple overlay
> clones of an existing container they should be registered in the lxc_snapshots
> file of the original container to stay consistent and adhere to the
> expectancies of the users. Most of all, it ensure that we cannot remove a
> container that has clones, even if they are just ephemeral snapshot-clones. The
> function adds further consistency because remove_snapshots_entry() ensures that
> ephemeral clone-snapshots deregister themselves from the lxc_snapshots file
> when they are destroyed.
> 
> POSSIBLE GLITCH:
> I was thinking hard about racing conditions and concurrent acces on the
> lxc_snapshots file when lxc-destroy is called on the container while we
> shutdown then container from inside. Here is what my thoughts are so far:
> 
> There should be no racing condition when lxc-destroy including all snapshots is

Note that lxcapi_destroy_with_snapshots() deletes the *snapshots*, not the
snapshot clones.  This is an unfortunate naming clash (which we could try
to correct henceforth but we need good names :), but they are different.
So anything under /var/lib/lxc/$container/snaps will be deleted.  But if
you've created an overlayfs clone, then containers listed in
/var/lib/lxc/$container/lxc_snapshots will not be deleted.  There is no
API call or program to automatically deleted those right now.  (I don't
think we want to write one, but a program to show which snapshots exist
would be good).

(Actually, there seems to be a bug right now - The sequence:

	lxc-create -t download -n w1 -- -d ubuntu -r wily -a amd64
	lxc-clone -s -B overlayfs -o w1 -n w2
	lxc-snapshot -n w2
	lxc-snapshot -n w2 -r snap0

does not result in /var/lib/lxc/w2/snap0 being deleted, so a subsequent

	lxc-destroy -n w2

is refused.

Do you have time to either look into that, or raise an issue on github
about it?

> called and the container in question is running, lxc-destroy will simply fail
> with the warning that the clone is still running but lxc-destroy won't touch
> the lxc_snapshots file. The offending container will then exit and delete the
> container entry. lxc-destroy can then be called again and will delete the
> remaining containers.
> 
> The strange case seems to be when we create another clone-snapshot while
> another one shuts down. Does someone have any arguments against this way of

This should be fine, because mod_rdep does a container_disk_lock(c0).  So
the inc and dec will be mutually exclusive.

> implementing it? Do we expect trouble? Do we need flocks in start.c and
> lxccontainer.c?
> 
> Christian Brauner (1):
>   Add remove_snapshots_entry()
> 
>  src/lxc/start.c | 123 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 123 insertions(+)
> 
> -- 
> 2.5.1
>