[CRIU] [PATCH 0/2] crit core-dump feature, v2

Ruslan Kuprieiev kupruser at gmail.com
Thu Apr 30 05:17:02 PDT 2015


On 30.04.15 14:48, Pavel Emelyanov wrote:
> On 04/30/2015 01:24 PM, Ruslan Kuprieiev wrote:
>>
>> On 30.04.15 13:12, Pavel Emelyanov wrote:
>>> Keeping pycriu in criu is OK, it's just an python API for images reading. But
>>> core-dumper can sit outside and use this API thus making sure that the API is
>>> usable:)
>>>
>>> -- Pavel
>> Pycriu package is not only about converting images. It also has rpc module
>> inside to give people easy access to criu rpc. core-dump belongs to
>> pycriu.images package as it takes care of CRIU images. Later we could
>> also add migration module i.e. pycriu.migrator.
> What's that?

pycriu.migrator? Theoretical python module that helps people to migrate 
their
processes and containers using python.

>> So people could use all
>> of that things in their applications through the python interface by simply
>> importing pycriu package that has everything they need in it.
>> And our cmdline utils as p.haul, crit decode/encode, crit core-dump are
>> just using pycriu module.
>>
>> I really think that keeping core_dump _python_ module outside of pycriu
>> or crit is very bad idea that will only make things complicated for
>> everyone.
> I agree that it's always hard to indentify really independent pieces. And
> as far as working with images is concerned, it looks natural to have a tool
> that provides and API to manipulate images in a generic form (part of pycriu
> does so) and to have the rest separate.

A tool is a crit -- cmdline utility. It uses pycriu python package, which
name says "i have a collection of multipurpose criu-related python
modules inside".

> On the other hand, I had in mind an ability to produce some stats about
> criu images and making it a part of crit itself. With the current discussion
> it seems that stats generator worth separate sub-project :)

Not crit itself, but pycriu! Someone might also like to use it in his
python app. CRIT is just a script to provide cmdline interface, real
functionality should be stored inside pycriu python package.

> Need to think.
>
>> I'm sure that users would rather like to have every pythonic criu-related
>> feature inside one pycriu python package and core-dump inside crit,
>> rather than having a zoo of lots of tools with different locations and
>> interfaces.
> Welcome to the unix world ;)

In unix world, you have for example "git send-email", "git rebase" and so on
(yeah, i know that some of them are just an aliases). "git" part is what 
makes
other commands united. Same thing with crit decode/encode core-dump.
Crit - CRiu Image Tool -- core-dump takes CRIU images and produces core 
dump,
so it should be within crit. Pycriu -- python binding for criu-things -- 
core-dump
takes CRIU images and produces core dump, so it should be within pycriu.
I can clearly see how someone could utilize pycriu.images.core_dump in his
debug project.

> -- Pavel



More information about the CRIU mailing list