[CRIU] Configuration files in master

[Pavel Emelyanov]

On 11/03/2017 10:29 AM, Adrian Reber wrote:
> Veronika and I discussed the missing things to get configuration file
> support merged into master.
> 
> The easy points are:
> 
>  * test was added with 4e68d555829e6095e878cc4f15892f5442651fd6 and runs
>    during every zdtm run

OK

>  * man page has a whole section called 'CONFIGURATION FILES'

Yup, found one :)

>  * wiki can easily be added based on the man page

Please.

> The difficult part is RPC and Veronika and I do not agree totally how to
> handle it and we are hoping for some input.
> 
> 
> The first question is if RPC should read configuration files at all.
> Looking at the ticket https://github.com/checkpoint-restore/criu/issues/278
> I would say that it is what user would expect. But the details get a bit
> complicated.
> 
> On the command-line the configuration file can be overrule by the CLI.
> 
> If the configuration file has 'tcp-established' I can tell CRIU with
> --no-tcp-established to ignore the value from the configuration file.

BTW, you've raised an interesting question -- how to tell --no-something
by using RPC?

> How should this be handled in the RPC case. My expectation would be that
> the configuration file can overwrite the settings from RPC. That can
> lead to strange behaviour if both sides in the migration have different
> configuration files. So maybe we would need the configuration file
> options listed in the criu log for RPC. Overwriting the RPC options with
> the configuration file means that we are using it the other way round
> then from CLI:
> 
>  CLI: first configuration file then CLI
>  RPC: first RPC option then configuration file

I see RPC as just another way to tell criu what to do, so if CLI options
override config file settings so should do the RPC commands.

> Another unclear point is what to do with options that be specified
> multiple times. Like verbosity=2 in the configuration file and two more
> verbosity options on the command line. For the CLI this means -v4 in the
> end right now. How to handle this case with RPC.

I'd do the same -- each RPC option is just an analogue to some CLI one, so
specifying an RPC one _or_ a CLI one shouldn't make any difference.

> So, please let us know what you think and what would be the 'right'
> solution.

-- Pavel