[CRIU] rewriting images via criu (or crit?)

[Tycho Andersen]

On Mon, Oct 27, 2014 at 06:04:39PM +0200, Ruslan Kuprieiev wrote:
> On 27.10.2014 17:32, Tycho Andersen wrote:
> >On Mon, Oct 27, 2014 at 05:10:33PM +0200, Ruslan Kuprieiev wrote:
> >>Hi all,
> >>
> >>I was recently thinking about converting/modifying images and i want to
> >>share some of my thoughts.
> >>For now I see 4 main ways:
> >>
> >>1) Use existing patch set for crit written in python.
> >>Pros:
> >>     1. Already works.
> >>     2. Python project is easy to support.
> >>     3. Adding xpath-like language for modifying images should be easy in
> >>Python.
> >>     4. All needed dependencies are available in (any?) repo.
> >>Cons:
> >>     1. Performance(maybe we could use Cython to make it better?).
> >>
> >>2) Rewrite crit in C
> >>Pros:
> >>     1. Performance.
> >>Cons:
> >>     1. C project is hard to support.
> >>     3. Adding xpath-like language for modifying images is not as easy as in
> >>Python.
> >>     4. Requires protobuf-c-text, which is quite new and isn't available in
> >>repos.
> >>
> >>3) Add crit functionality to criu ("criu convert", "criu modify").
> >>Pros:
> >>     1. Performance
> >>     2. Allows us to reuse a bunch of existing code.
> >>     3. Having such tool shipped along with "criu show" looks like a nice
> >>feature.
> >>     4. We can easily teach criu how to use images in text format, which
> >>seems
> >>         quite handy.
> >>Cons:
> >>     1. criu is already complex enough and adding more stuff might be too
> >>much,
> >>         especially xpath-like language engine.
> >>     2. Hard to support.
> >>     3. Requires protobuf-c-text, which is quite new and isn't available in
> >>repos.
> >>     4. Requires heavy patching to existing code.
> >>
> >>4) Use 1), but for _high-speed_ image modification use criu plugins and
> >>hooks
> >>     to modify images on restore.
> >>Pros:
> >>     1. Performance.
> >>     2. No heavy patching.
> >>Cons:
> >>     Can't see any.
> >>
> >>I prefer 4) because it seems like a good compromise.
> >>What do you guys think?
> >Does that mean we'd need to expose all the protobuf headers? Will
> >users then need to link against libprotobuf?
> 
> We would need to expose proto files with crit anyway(just the way we are
> shipping rpc.proto), so exposing protobuf headers shouldn't be a problem.

Why do we need to expose the proto files if we have the language to
modify the images?

> Plugin indeed should be linked against libprotobuf-c. Is that a problem?

It would take some amount of non-trivial work for lxc to link against
libprotobuf-c (lxc is in the main ubuntu archive, so all of its
dependencies must be too; the main archive has extra reviews and
restrictions). Not to say it couldn't be done, but it would be nice to
avoid it.

Another major benefit is that the proto files are essentially an
internal API for criu. When we make changes to the proto files, we can
do that as long as we write some code that handles the old style
images. If we make these "public", then we have to have some way to
version them.

> I mean, yes, plugin isn't very flexible tool, but it should be faster than
> calling
> a separate tool to modify image. For flexibility one could use crit written
> in python.

Isn't it mostly just saving you an extra fork()? Assuming the
performance critical bits of crit were written in C, shouldn't it be
essentially equivalent to doing it in criu?

Tycho