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

[Andrei Vagin]

On Wed, May 30, 2018 at 12:13:21PM +0200, Adrian Reber wrote:
> 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.

Adrian, do you have any news?

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