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

[Tycho Andersen]

On Tue, Oct 21, 2014 at 12:56:24PM +0400, Cyrill Gorcunov wrote:
> On Mon, Oct 20, 2014 at 07:22:53PM -0500, Tycho Andersen wrote:
> > Hi all,
> > 
> > One of the problems we talked about at Plumbers was how to re-write cgroups. For
> > example, if you migrate a container from a node with 4 cores (and thus a
> > cpuset.cpus of 0-3), to a node with two cores (cpuset = 0-1), a write of 0-3
> > into the new host's cpuset.cpus will fail, and the restore will fail.
> > 
> > Thus, we need some way to re-write these things (and images in general) so that
> > we can handle this case and others. One option is to have a small syntax to
> > rewrite things, and add support to the new crit tool either in C or in python
> > depending on speed concerns to rewrite the images. Stealing some inspiration
> > from xpath, below is my proposal for a language that does this rewriting.
> > 
> > In our example above, we want to write cpuset.cpus everywhere from 0-3 to 0-1:
> > 
> > cgroup_entry.controllers["cpuset" in cnames]//properties[name="cpuset.cpus"] set value=0-1
> > 
> > That is, first, match the buffer message type "cgroup_entry" with any
> > controllers who have "cpuset" in them (the 'in' here would only work for
> > 'repeated' message types), "//" says "recursively match any object with...",
> > properties[name="cpuset.cpus"] says match any object in properties where the
> > name is "0-3". Finally, set (get, delete) says what to do, and value says 'set
> > the value member of each matching object to "0-3"'.
> > 
> > To do something a bit simpler, like setting a tasks exit code, you could do:
> > 
> > core_entry.tc set exit_code=1
> > 
> > That is, match all core entries' (there is only one in each image) tc object
> > without constraints, and set the exit_code value to 1.
> > 
> > Some images have binary data in them, which we can just ignore for now.
> > 
> > The motivation for having a language (vs. just exposing the .proto definitions
> > and allowing users to use the images directly) is that we don't want to force
> > users to link against libprotobuf.
> > 
> > Does this sound reasonable? Anyone have any ideas on how to do this in a more
> > succinct (but still flexible :) fashion?
> 
> As to me -- external tool for such modifications is better choise and it seems
> crit is exactly fits here. This might have slight impact on the speed in compare
> if the language would builtin into criu itself, but criu is already complex enough
> so adding language engine here would simply overload I think.

Yes, agreed. I think crit is the best place for this. I hope that it
won't have a huge speed impact, we could parse the language in
python, but then use C to do the actual rewriting if it turns out to be
a bottleneck.

Tycho