I’m fully share Nick’s point of view on this. If you change any configuration parameter in runtime then go ahead and update your static configuration or a set of DDL statements that are only used during a cluster restart.
— Denis > On Aug 22, 2017, at 7:13 PM, Nick Pordash <[email protected]> wrote: > > 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. >>
