[CRIU] [GSoC 2019] Interested in CRIU project

[Adrian Reber]

On Fri, Mar 15, 2019 at 01:40:02PM +0000, Pavel Emelianov wrote:
> On 3/15/19 9:20 AM, James Cui wrote:
> > So the conclusion is to put code into go-criu and reimplements functionality in criu/lib/py right?
> 
> Well, hopefully Adrian supports me on this -- yes put the code into go-criu, but keep the
> existing py code to let other people work on the anonymizing images task. If we find out
> we have time in summer to move even the new code -- we'll slightly correct the plan.

Totally agree.

> > Also are there any code that I'd better to look at in go-criu to prepare this project?
> 
> Adrian?

Not sure I totally get that question. If it is about existing code in
co-criu, there is not much code besides the RPC definition, the version
check and the p-haul Go implementation.

If it is about similar code, there is something in LXD and it is
mentioned on the CRIU GSoC topic wiki page. That would probably be a
good start.

There is also the Python implementation which is the current reference
implementation.

		Adrian

> > On Wed, Mar 13, 2019 at 11:02 AM Pavel Emelianov <xemul at virtuozzo.com <mailto:xemul at virtuozzo.com>> wrote:
> > 
> >     On 3/13/19 7:51 PM, Adrian Reber wrote:
> >     > On Wed, Mar 13, 2019 at 02:56:52PM +0000, Pavel Emelianov wrote:
> >     >> On 3/13/19 5:44 PM, Adrian Reber wrote:
> >     >>> On Wed, Mar 13, 2019 at 02:26:27PM +0000, Pavel Emelianov wrote:
> >     >>>> On 3/13/19 11:10 AM, Adrian Reber wrote:
> >     >>>>> On Tue, Mar 12, 2019 at 09:14:47PM -0700, James Cui wrote:
> >     >>>>>> Thanks Pavel and Adrian for the answers!
> >     >>>>>> One question though. For the go implementation of CRIT, will it live in the
> >     >>>>>> same repo of CRIU or some other repo (For example, I create my own repo in
> >     >>>>>> github)?
> >     >>>>>> I asked because I saw a repo called go-CRIU, is this the place all go
> >     >>>>>> implementation should be?
> >     >>>>>
> >     >>>>> I think it should live in the go-criu repository. I think it should be a
> >     >>>>> library which can be used by the new CRIT implementation but also be
> >     >>>>> used by other projects which need to read or write CRIU image files.
> >     >>>>
> >     >>>> Now a question from me :) Do we want to continue maintaining both criu
> >     >>>> libs -- go anf py -- or make py version call the go one?
> >     >>>
> >     >>> Good question. Not sure.
> >     >>>
> >     >>> I think we need a go version at some point, so it makes sense to have
> >     >>> it. For LXD precopy migration I already implemented some image file
> >     >>> reading into LXD and it would make sense to maintain the image file
> >     >>> manipulation for Go in one place. But if it is maintained in the go-criu
> >     >>> repository it will not be automatically available for anyone checking
> >     >>> out CRIU. Which currently is really nice, you check out CRIU and you
> >     >>> have (python) CRIT for debugging.
> >     >>
> >     >> Absolutely.
> >     >>
> >     >>> On the other hand if we have Go CRIT, which is also embedded into other
> >     >>> projects, it does not make sense to keep the Python CRIT libraries.
> >     >>
> >     >> But the CRIT tool itself -- should it also become golang-written in this case?
> >     >
> >     > Would make sense.
> > 
> >     OK
> > 
> >     >>> I guess we wait if it works as good as the Python version or better and
> >     >>> decide then how we want to use it.
> >     >>
> >     >> Yes, but the reason I'm asking is the "anonymize image files" task for this
> >     >> GSoC. I guess it will be done on the py-crit basis, so we'll have two not equal
> >     >> sets of functionalities in py vs go right at once :)
> >     >
> >     > So, hmm, it seems we did not coordinate our GSoC topics.
> > 
> >     ^_^
> > 
> >     > Right now I
> >     > would say, let's first wait which of our topics are people interested in
> > 
> >     https://criu.org/GSoC19_Students_Requests
> > 
> >     and we have both -- go-images and anon-images covered.
> > 
> >     > and once we actually have results, we need to figure out which way we
> >     > want to go. Maybe the Go part is only a library and CRIT stays python
> >     > based, or maybe add the "anonymize image files" also to the Go
> >     > implementation.
> >     >
> >     > Not really sure how to best handle this. Any other ideas from you?
> > 
> >     I agree with your proposal to start going with what we have and do anonymizer
> >     in py and go-images from scratch for your needs first and see how it will go.
> > 
> >     -- Pavel
> > 
>