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

[Adrian Reber]

On Fri, May 18, 2018 at 05:21:10PM +0300, Pavel Emelyanov wrote:
> 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.

I will rework my patches and send a new version.

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

Also a good idea, but I will ignore it for now ;)

		Adrian