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

[Pavel Emelyanov]

On 04/30/2015 03:17 PM, Ruslan Kuprieiev wrote:
> 
> 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.

Actually pycriu.migrator is the p.haul sub-project :) And if we ever implement
the seamless kernel update with criu the software doing _this_ will not sit in
criu repo, will have some own name but will still use criu as a part.

>>> 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".

Yup. But think of it this way -- we may imagine other stuff doing checkpoint,
for example old openvz cpt modules, blcr, dmtcp. Producing core out of image
files can be done for any of them. Now let's check what's the majority of code
doing this conversion is about -- about messing with checkpoint images, or
about messing the ELF files?

>> 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. 

Agreed, but gitk is not part of git while it uses git and only git.

> 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