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

[Adrian Reber]

On Fri, Jun 08, 2018 at 12:02:38AM -0700, Andrei Vagin wrote:
> 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?

Unfortunately not yet. I am busy with other parts of CRIU, but I have
not forgotten about this.

		Adrian