[CRIU] Configuration directory /etc/criu.d

[Tycho Andersen]

Hi guys,

Sorry I'm late to the party :)

On Fri, Aug 05, 2016 at 06:02:49PM +0200, Adrian Reber wrote:
> 
> Having added the skip in-flight TCP connections option to TCP I thought
> something else is needed to influence CRIU's behavior. Every tool using
> CRIU (docker, lxc, runc, ...) hardcodes the required options into the
> source code and every change to CRIU requires a change in all tools.
> 
> Therefore I thought it would be nice to have something like
> 
> /etc/criu.d/ or ~/.criu.d/
> 
> where CRIU would look for .conf files which can enable or disable
> options for all CRIU invocations.
> 
> Staying at my skip in-flight TCP connections example I could just add a
> file to /etc/criu.d which always enables --skip-in-flight for CRIU
> invocations on that system. There should then also be a way to disable
> options from hardcoded CRIU invocations in higher tools like docker and
> lxc. I would also expect an option to ignore files in /etc/criu.d.
> 
> https://github.com/xemul/criu/issues/194 is good example where it could
> also help.
> 
> Is this something which would be useful to CRIU? Any other opinions?

I think this is something that would be useful, and I've considered
proposing something like this in the past. In particular, I think
there are a few different ways to use CRIU:

* in an "I don't care what fails, just migrate the damn thing" mode.
  In many cases where CRIU fails, the container could still be
  migrated, but one small piece of the container might have been
  migrated "wrong". When operating in this mode, CRIU would just
  charge on ahead in the face of all but the most fatal failures.

* what we currently have today, say "normal" mode

* in a "please get this exactly right mode", this would be stuff such
  as --manage-cgroups=strict, etc.

I think the last two are mostly just a collection of settings, but the
first one would require actual patches to CRIU to get to work. Anyway,
down the road I can see us in LXD wanting something like this, so
presumably everyone would want something like this. Definitely a first
step would be sharing collections of configurations as you've
suggested, Adrian.

I hadn't proposed it to the list yet because I don't have the cycles
to work on it right now, but I'm happy to try an adopt any work that
comes out of this in liblxc :)

Tycho

> 		Adrian
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu