<div dir="auto">Thanks Pavel and Adrian for answers!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019, 6:53 AM Adrian Reber <<a href="mailto:areber@redhat.com">areber@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Mar 15, 2019 at 01:40:02PM +0000, Pavel Emelianov wrote:<br>
> On 3/15/19 9:20 AM, James Cui wrote:<br>
> > So the conclusion is to put code into go-criu and reimplements functionality in criu/lib/py right?<br>
> <br>
> Well, hopefully Adrian supports me on this -- yes put the code into go-criu, but keep the<br>
> existing py code to let other people work on the anonymizing images task. If we find out<br>
> we have time in summer to move even the new code -- we'll slightly correct the plan.<br>
<br>
Totally agree.<br>
<br>
> > Also are there any code that I'd better to look at in go-criu to prepare this project?<br>
> <br>
> Adrian?<br>
<br>
Not sure I totally get that question. If it is about existing code in<br>
co-criu, there is not much code besides the RPC definition, the version<br>
check and the p-haul Go implementation.<br>
<br>
If it is about similar code, there is something in LXD and it is<br>
mentioned on the CRIU GSoC topic wiki page. That would probably be a<br>
good start.<br>
<br>
There is also the Python implementation which is the current reference<br>
implementation.<br>
<br>
Adrian<br>
<br>
> > On Wed, Mar 13, 2019 at 11:02 AM Pavel Emelianov <<a href="mailto:xemul@virtuozzo.com" target="_blank" rel="noreferrer">xemul@virtuozzo.com</a> <mailto:<a href="mailto:xemul@virtuozzo.com" target="_blank" rel="noreferrer">xemul@virtuozzo.com</a>>> wrote:<br>
> > <br>
> > On 3/13/19 7:51 PM, Adrian Reber wrote:<br>
> > > On Wed, Mar 13, 2019 at 02:56:52PM +0000, Pavel Emelianov wrote:<br>
> > >> On 3/13/19 5:44 PM, Adrian Reber wrote:<br>
> > >>> On Wed, Mar 13, 2019 at 02:26:27PM +0000, Pavel Emelianov wrote:<br>
> > >>>> On 3/13/19 11:10 AM, Adrian Reber wrote:<br>
> > >>>>> On Tue, Mar 12, 2019 at 09:14:47PM -0700, James Cui wrote:<br>
> > >>>>>> Thanks Pavel and Adrian for the answers!<br>
> > >>>>>> One question though. For the go implementation of CRIT, will it live in the<br>
> > >>>>>> same repo of CRIU or some other repo (For example, I create my own repo in<br>
> > >>>>>> github)?<br>
> > >>>>>> I asked because I saw a repo called go-CRIU, is this the place all go<br>
> > >>>>>> implementation should be?<br>
> > >>>>><br>
> > >>>>> I think it should live in the go-criu repository. I think it should be a<br>
> > >>>>> library which can be used by the new CRIT implementation but also be<br>
> > >>>>> used by other projects which need to read or write CRIU image files.<br>
> > >>>><br>
> > >>>> Now a question from me :) Do we want to continue maintaining both criu<br>
> > >>>> libs -- go anf py -- or make py version call the go one?<br>
> > >>><br>
> > >>> Good question. Not sure.<br>
> > >>><br>
> > >>> I think we need a go version at some point, so it makes sense to have<br>
> > >>> it. For LXD precopy migration I already implemented some image file<br>
> > >>> reading into LXD and it would make sense to maintain the image file<br>
> > >>> manipulation for Go in one place. But if it is maintained in the go-criu<br>
> > >>> repository it will not be automatically available for anyone checking<br>
> > >>> out CRIU. Which currently is really nice, you check out CRIU and you<br>
> > >>> have (python) CRIT for debugging.<br>
> > >><br>
> > >> Absolutely.<br>
> > >><br>
> > >>> On the other hand if we have Go CRIT, which is also embedded into other<br>
> > >>> projects, it does not make sense to keep the Python CRIT libraries.<br>
> > >><br>
> > >> But the CRIT tool itself -- should it also become golang-written in this case?<br>
> > ><br>
> > > Would make sense.<br>
> > <br>
> > OK<br>
> > <br>
> > >>> I guess we wait if it works as good as the Python version or better and<br>
> > >>> decide then how we want to use it.<br>
> > >><br>
> > >> Yes, but the reason I'm asking is the "anonymize image files" task for this<br>
> > >> GSoC. I guess it will be done on the py-crit basis, so we'll have two not equal<br>
> > >> sets of functionalities in py vs go right at once :)<br>
> > ><br>
> > > So, hmm, it seems we did not coordinate our GSoC topics.<br>
> > <br>
> > ^_^<br>
> > <br>
> > > Right now I<br>
> > > would say, let's first wait which of our topics are people interested in<br>
> > <br>
> > <a href="https://criu.org/GSoC19_Students_Requests" rel="noreferrer noreferrer" target="_blank">https://criu.org/GSoC19_Students_Requests</a><br>
> > <br>
> > and we have both -- go-images and anon-images covered.<br>
> > <br>
> > > and once we actually have results, we need to figure out which way we<br>
> > > want to go. Maybe the Go part is only a library and CRIT stays python<br>
> > > based, or maybe add the "anonymize image files" also to the Go<br>
> > > implementation.<br>
> > ><br>
> > > Not really sure how to best handle this. Any other ideas from you?<br>
> > <br>
> > I agree with your proposal to start going with what we have and do anonymizer<br>
> > in py and go-images from scratch for your needs first and see how it will go.<br>
> > <br>
> > -- Pavel<br>
> > <br>
> <br>
</blockquote></div>