ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Pordash <nickpord...@gmail.com>
Subject Re: Ignite: configuration changes at runtime
Date Wed, 23 Aug 2017 02:13:57 GMT
The notion of saving changes to a configuration file does not make sense
for lots of use cases, Kubernetes is one example. Anything in the
container's filesystem is considered transient since it will get destroyed
when a pod is restarted.

I would think that runtime changes should be managed in the cluster
metadata somewhere instead of expecting them to be exported elsewhere like
a file. If new nodes join the cluster then runtime changes received as a
part of a node join operation would get applied prior to node activation
from completing. These would override any node configuration provided on
node startup, regardless of how it was configured.

IMO if someone wants to make runtime changes AND propagate those changes to
wherever they are doing external configuration management then perhaps that
should be left as an exercise for the user. There are so many ways that
this could be done and often what is sitting on the filesystem would easily
get overridden by some other mechanism (f.e ansible, salt, puppet, chef,
container orchestration systems, etc).


On Tue, Aug 22, 2017, 6:54 PM Dmitriy Setrakyan <dsetrakyan@apache.org>

> On Tue, Aug 22, 2017 at 4:43 AM, Yakov Zhdanov <yzhdanov@apache.org>
> wrote:
> > >Not really. What if the user configured Ignite from Java API, without
> any
> > >XML. What will be saved? To prevent this ambiguity, I think the cleanest
> > >way is to ask user to save the configuration to a file explicitly.
> >
> > I think it does not matter too much how the grid was configured. In any
> > case IgniteConfiguration object is created. And we will be allowing to
> > change only very few parameters that are mostly of primitive type or
> enum.
> >
> > Once changed configuration is saved to metastore. When restarting we
> should
> > apply it by default or allow user to override it with provided one.
> >
> I would prefer that users explicitly specify which configuration file to
> use on startup. This will prevent any magic. Still think that explicit call
> to saveConfigurationFile(...) is the best approach.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message