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

[Pavel Emelyanov]

On 05/18/2018 08:46 AM, Adrian Reber wrote:
> 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.

That's good news :)

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

I would say we need an additional parameter. Explicit is better than implicit.

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

Yup.

BTW, another option might be to create an RPC tunnel %) Like in criu_opts
we define an optional 'string more_opts' variable and teach ldx and runc
pass this string as-is from caller to criu. Criu then decodes this value
into criu_opts structure and overrides the options that has been just set
from config and RPC...

-- Pavel