On Thu, Aug 17, 2017 at 10:37 AM, Yakov Zhdanov <[email protected]> wrote:
> >I don't like the idea of intermixing changeable properties with constant > >ones in the configuration. Moreover, the standard configuration class is > >local to the node, while changing the config properties at runtime may be > a > >distributed operation that needs to be propagated across the cluster. > > I don't 100% agree here. Let's discuss. > I will take your 99% :) > > 1. I would not mess with propagation for now. Propagation can be handled by > special methods or by Visor/WebConsole > I think providing API is important for users who want to integrate Ignite with their own management tools. > 2. If we choose to create separate managing objects we end up in creating > that for each configuration type we have now. And we have quite great > number of config objects. For me personally, it seems more convenient to > have configuration object a place to change and retrieve current > configuration. We can have separate method to apply the changes (on > configuration object or object that is configured by that configuration > object). > I think it is a design decision. Do we have enough config properties that can be changed at runtime to merit a separate config object? Or can we group them all in one runtime config? > > >How about we add getters and setters to IgniteConfigurationRuntime > >interface. BTW, this interface should also become an MBean, so it can be > >managed by external tools. > > Again, if we introduce separate runtime configurable object this seems to > be very confusing. After I change the property via that object, should > corresponding property change in let's say IgniteConfiguration? > No, the Ignite configuration is what Ignite receives on startup. Runtime changes are outside of configuration, especially given that if cluster restarts, they are likely lost. > > --Yakov >
