[CRIU] [PATCH v2 2/4] Track which configuration options have been changed

[Adrian Reber]

On Thu, May 17, 2018 at 03:02:52PM +0300, Pavel Emelyanov wrote:
> 
> >> Trying to make config file become docker-transparend-cli doesn't just "looks wrong",
> >> it's also problematic since fixing a global config would affect every single CRIU 
> >> invocation that might happen in between. To get a "CLI/RPC overrider" we need
> >> something, that it local to a single CRIU invocation... maybe another "local" or
> >> "one-shot" config file, that CRIU will read after reading the global one and parsing
> >> CLI/RPC. But can we tell CRIU where this one-shot file is through docker/lxd call?
> > 
> > Pavel, thanks for your comments, although I am not sure what you
> > propose. So for RPC you basically say we do not want to have
> > configuration files, right? 
> 
> Not exactly. We may still use them, but in the "low prio" mode, i.e. the options
> passed via RPC shoudl take priority over those read from config.
> 
> > So should we merge the CLI patches?
> 
> Yes, since ...
> 
> > Everything concerning the CLI patches seems to be as everyone expects.
> 
> ... this :)
> 
> > I guess I understand the 'one-shot' idea but I am also not sure how it
> > should work. Maybe you are also not sure ;) 
> 
> Yup :( I remember the problem, but still have no good answer for it.
> 
> > We are looking for mechanism> to influence LXD (which uses CLI) and docker/runc (which uses RPC). But
> > it should be different than configuration files, right?
> 
> My idea was to introduce two config files for criu. The first one is exsting one, that
> criu reads from known global place (/etc/...). Then criu parses CLI/RPC options and 
> overrides values read from config. Then should go the 2nd config, which is formatted
> the same way as the 1st one, but it sits not in some other place path to which is
> somehow (I don't know how to pass this knowledge "through" docker/lxd) told to criu
> by the caller. This 2nd config file will override options set via CLI/RPC. Also, since
> the path to this 2nd config file is specified by the caller, if some other criu invocation
> happens in parallel it will not erroneously pick this file's options.

Sounds good. I would say we have no problem changing the latest LXC and
runc to adapt to this functionality. We already have "--config FILEPATH"
so we can tell CRIU to load a specific configuration file.

So should CRIU, in the RPC and CLI case, just behave differently if a
non-default location for the config file is specified? As soon as
CLI/RPC sees '--config FILEPATH' this config file is evaluated after the
CLI/RPC arguments, or do we want an additional parameter which switches
CRIU explicitly into config-file-overrides CLI/RPC parameters?

The good thing about being explicit is that it will not be a unexpected
behavior as the user has to explicitly request it. As we probably have
to change LXC and runc anyway it would be no problem to specify both
'--config FILEPATH' and '--override-rpc/cli'. We could also combine it
with something like '--override-rpc/cli-with FILEPATH'.

Is that something which makes sense?

		Adrian