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

[Ruslan Kuprieiev]

On 21.10.2014 11:56, 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.

I totally agree with Cyrill.

I like the syntax. Are you thinking about using crit like so:
crit modify -i cgroup.img cgroup_entry.controllers["cpuset" in 
cnames]//properties[name="cpuset.cpus"] set value=0-1
right?