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). -Nick On Tue, Aug 22, 2017, 6:54 PM Dmitriy Setrakyan <[email protected]> wrote: > On Tue, Aug 22, 2017 at 4:43 AM, Yakov Zhdanov <[email protected]> > 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. >
