You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Yakov Zhdanov <yz...@apache.org> on 2017/08/11 15:49:18 UTC
Ignite: configuration changes at runtime
Hello Igniters!
I want to start a discussion on a pretty useful feature that will help us
to bring Ignite's usability to the next level. How about supporting changes
to (some) configuration at runtime? Currently, most of the config props are
carved in stone and will require node restart for a change.
On this page I tried to summarize the vision and put the most important
properties (from my perspective) that will be handy to change at runtime:
https://cwiki.apache.org/confluence/display/IGNITE/Allow+Configuration+Settings+Change+At+Runtime
Alex Goncharuk, can you please help to fill in the suggestions for
persistence and memory config?
After we agree on properties list then I will file a ticket to implement
mechanism for properties propagation (via custom event or via ordinary
communication) and tickets for each Ignite's configuration bean and SPIs.
Comments are welcome.
--Yakov
Re: Ignite: configuration changes at runtime
Posted by Yakov Zhdanov <yz...@apache.org>.
>I would also add to CacheConfiguration:
> StatisticsEnabled: on / off
> QueryDetailMetricsSize: change size
Alex, feel free to put your suggestions to the page.
>Please also implement an API that could be used from UI tools (Web Console
> and Visor Cmd).
Of course we will implement API and initiate corresponding changes in
WebConsole and Visor.
--Yakov
Re: Ignite: configuration changes at runtime
Posted by Alexey Kuznetsov <ak...@apache.org>.
Yakov,
Very cool feature.
I would also add to CacheConfiguration:
StatisticsEnabled: on / off
QueryDetailMetricsSize: change size
Please also implement an API that could be used from UI tools (Web Console
and Visor Cmd).
On Fri, Aug 11, 2017 at 10:49 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> Hello Igniters!
>
> I want to start a discussion on a pretty useful feature that will help us
> to bring Ignite's usability to the next level. How about supporting changes
> to (some) configuration at runtime? Currently, most of the config props are
> carved in stone and will require node restart for a change.
>
> On this page I tried to summarize the vision and put the most important
> properties (from my perspective) that will be handy to change at runtime:
> https://cwiki.apache.org/confluence/display/IGNITE/
> Allow+Configuration+Settings+Change+At+Runtime
>
> Alex Goncharuk, can you please help to fill in the suggestions for
> persistence and memory config?
>
> After we agree on properties list then I will file a ticket to implement
> mechanism for properties propagation (via custom event or via ordinary
> communication) and tickets for each Ignite's configuration bean and SPIs.
>
> Comments are welcome.
>
> --Yakov
>
--
Alexey Kuznetsov
Re: Ignite: configuration changes at runtime
Posted by Alexey Kuznetsov <ak...@apache.org>.
Just as idea...
Can we have reference to read-only "initialConfig" - a config node was
started with.
And current "mutable via special API" config?
Having this we could show in some management tool what was changed
(for example, TeamCity has such functionality - history of who and what
was changed in build properties).
On Fri, Aug 18, 2017 at 3:57 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> Here is the list of params that can be changed - https://cwiki.apache.org/
> confluence/display/IGNITE/Allow+Configuration+Settings+Change+At+Runtime
>
> >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.
>
> Again, how you provide all-in-one-place current node configuration? Also,
> why changes should be lost? In case of persistence they should not be lost,
> moreover, nodes joining with previous configuration should pick up current
> properties of running nodes.
>
> >I think providing API is important for users who want to integrate Ignite
> >with their own management tools.
>
> This maybe done via JMX. Currently, I guess we expose only configuration
> toString() via it.
>
> --Yakov
>
--
Alexey Kuznetsov
Re: Ignite: configuration changes at runtime
Posted by Denis Magda <dm...@apache.org>.
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 <ni...@gmail.com> 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 <ds...@apache.org>
> wrote:
>
>> On Tue, Aug 22, 2017 at 4:43 AM, Yakov Zhdanov <yz...@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.
>>
Re: Ignite: configuration changes at runtime
Posted by Nick Pordash <ni...@gmail.com>.
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 <ds...@apache.org>
wrote:
> On Tue, Aug 22, 2017 at 4:43 AM, Yakov Zhdanov <yz...@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.
>
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Tue, Aug 22, 2017 at 4:43 AM, Yakov Zhdanov <yz...@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.
Re: Ignite: configuration changes at runtime
Posted by Yakov Zhdanov <yz...@apache.org>.
>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.
--Yakov
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Aug 21, 2017 at 6:20 PM, Alexey Kuznetsov <ak...@apache.org>
wrote:
> Guys,
>
> Why not to let user to decide whether to persist changed properties or not?
> We could have a Boolean flag on API "persist=true|false".
>
> Make sense?
>
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.
Makes sense?
> On Tue, Aug 22, 2017 at 6:52 AM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > On Mon, Aug 21, 2017 at 7:28 AM, Alexey Dmitriev <admitriev@gridgain.com
> >
> > wrote:
> >
> > > I believe it should be persistent.
> > > We can have a parameter about "reset configuration on restart", which
> can
> > > be also OLCC-compatible
> > >
> >
> > Alexey, the problem with persisting at all times is that some properties
> > may be set directly from code. What is wrong with persisting when user
> > explicitly calls saveToFile method?
> >
> >
> > >
> > > On Mon, Aug 21, 2017 at 5:22 PM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > wrote:
> > >
> > > > On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev <
> > admitriev@gridgain.com
> > > >
> > > > wrote:
> > > >
> > > > > I would say it should as soon as we moving to "persistence".
> > > > > It will require to look at the things a bit different than before,
> > but
> > > I
> > > > > would say that's an evolution for the product.
> > > > > We probably also should think how our configuration system should
> be
> > > > > changed to make it more obvious.
> > > > >
> > > >
> > > > But in that case, what to do with XML configuration? Should it be
> > updated
> > > > as well? Or even worse, what if user added configuration from code?
> > > >
> > > > On Mon, Aug 21, 2017 at 5:11 PM, Dmitriy Setrakyan <
> > > dsetrakyan@apache.org>
> > > > > wrote:
> > > > >
> > > > > > I think the main question I have is whether this configuration
> > change
> > > > > will
> > > > > > survive restarts. Part of me says it should, and the other part
> > says
> > > it
> > > > > > shouldn't.
> > > > > >
> > > > > > Does anyone have a strong opinion about this?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev <
> > > > admitriev@gridgain.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > It looks like very useful and natural thing having the
> parameters
> > > > > change
> > > > > > on
> > > > > > > the fly.
> > > > > > > Maybe we should design something like OLCC (on-line
> configuration
> > > > > change)
> > > > > > > module, which will request different procedures for different
> > bunch
> > > > of
> > > > > > > parameters.
> > > > > > > All the parameters, this way, will be splitted into several
> > groups.
> > > > > > > For example in the worst case, when all the grid has to be
> > > > synchronized
> > > > > > for
> > > > > > > particular parameter change, some preparation on the grid has
> to
> > be
> > > > > > > performed, than when all the nodes reports readiness, the
> > parameter
> > > > > > change
> > > > > > > could be initiated.
> > > > > > > On the opposite if it is parameter configured per node, OLCC
> > state
> > > > > > machine
> > > > > > > will work simpler without inter-node communication.
> > > > > > >
> > > > > > > On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <
> > > yzhdanov@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > >I see your point. In this case, we should have a special
> > package
> > > > > > > > containing
> > > > > > > > >all the runtime config properties.
> > > > > > > >
> > > > > > > > Dmitry, I think this will be a mess.
> > > > > > > >
> > > > > > > > Igniters, any more opinions?
> > > > > > > >
> > > > > > > > --Yakov
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alexey Dmitriev, VP Engineering
> > > > > > > *GridGain Systems*
> > > > > > > www.gridgain.com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alexey Dmitriev, VP Engineering
> > > > > *GridGain Systems*
> > > > > www.gridgain.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Dmitriev, VP Engineering
> > > *GridGain Systems*
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
>
Re: Ignite: configuration changes at runtime
Posted by Alexey Kuznetsov <ak...@apache.org>.
Guys,
Why not to let user to decide whether to persist changed properties or not?
We could have a Boolean flag on API "persist=true|false".
Make sense?
On Tue, Aug 22, 2017 at 6:52 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Mon, Aug 21, 2017 at 7:28 AM, Alexey Dmitriev <ad...@gridgain.com>
> wrote:
>
> > I believe it should be persistent.
> > We can have a parameter about "reset configuration on restart", which can
> > be also OLCC-compatible
> >
>
> Alexey, the problem with persisting at all times is that some properties
> may be set directly from code. What is wrong with persisting when user
> explicitly calls saveToFile method?
>
>
> >
> > On Mon, Aug 21, 2017 at 5:22 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > wrote:
> >
> > > On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev <
> admitriev@gridgain.com
> > >
> > > wrote:
> > >
> > > > I would say it should as soon as we moving to "persistence".
> > > > It will require to look at the things a bit different than before,
> but
> > I
> > > > would say that's an evolution for the product.
> > > > We probably also should think how our configuration system should be
> > > > changed to make it more obvious.
> > > >
> > >
> > > But in that case, what to do with XML configuration? Should it be
> updated
> > > as well? Or even worse, what if user added configuration from code?
> > >
> > > On Mon, Aug 21, 2017 at 5:11 PM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > > wrote:
> > > >
> > > > > I think the main question I have is whether this configuration
> change
> > > > will
> > > > > survive restarts. Part of me says it should, and the other part
> says
> > it
> > > > > shouldn't.
> > > > >
> > > > > Does anyone have a strong opinion about this?
> > > > >
> > > > > D.
> > > > >
> > > > > On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev <
> > > admitriev@gridgain.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > It looks like very useful and natural thing having the parameters
> > > > change
> > > > > on
> > > > > > the fly.
> > > > > > Maybe we should design something like OLCC (on-line configuration
> > > > change)
> > > > > > module, which will request different procedures for different
> bunch
> > > of
> > > > > > parameters.
> > > > > > All the parameters, this way, will be splitted into several
> groups.
> > > > > > For example in the worst case, when all the grid has to be
> > > synchronized
> > > > > for
> > > > > > particular parameter change, some preparation on the grid has to
> be
> > > > > > performed, than when all the nodes reports readiness, the
> parameter
> > > > > change
> > > > > > could be initiated.
> > > > > > On the opposite if it is parameter configured per node, OLCC
> state
> > > > > machine
> > > > > > will work simpler without inter-node communication.
> > > > > >
> > > > > > On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <
> > yzhdanov@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > >I see your point. In this case, we should have a special
> package
> > > > > > > containing
> > > > > > > >all the runtime config properties.
> > > > > > >
> > > > > > > Dmitry, I think this will be a mess.
> > > > > > >
> > > > > > > Igniters, any more opinions?
> > > > > > >
> > > > > > > --Yakov
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alexey Dmitriev, VP Engineering
> > > > > > *GridGain Systems*
> > > > > > www.gridgain.com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Dmitriev, VP Engineering
> > > > *GridGain Systems*
> > > > www.gridgain.com
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Dmitriev, VP Engineering
> > *GridGain Systems*
> > www.gridgain.com
> >
>
--
Alexey Kuznetsov
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Aug 21, 2017 at 7:28 AM, Alexey Dmitriev <ad...@gridgain.com>
wrote:
> I believe it should be persistent.
> We can have a parameter about "reset configuration on restart", which can
> be also OLCC-compatible
>
Alexey, the problem with persisting at all times is that some properties
may be set directly from code. What is wrong with persisting when user
explicitly calls saveToFile method?
>
> On Mon, Aug 21, 2017 at 5:22 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev <admitriev@gridgain.com
> >
> > wrote:
> >
> > > I would say it should as soon as we moving to "persistence".
> > > It will require to look at the things a bit different than before, but
> I
> > > would say that's an evolution for the product.
> > > We probably also should think how our configuration system should be
> > > changed to make it more obvious.
> > >
> >
> > But in that case, what to do with XML configuration? Should it be updated
> > as well? Or even worse, what if user added configuration from code?
> >
> > On Mon, Aug 21, 2017 at 5:11 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > > wrote:
> > >
> > > > I think the main question I have is whether this configuration change
> > > will
> > > > survive restarts. Part of me says it should, and the other part says
> it
> > > > shouldn't.
> > > >
> > > > Does anyone have a strong opinion about this?
> > > >
> > > > D.
> > > >
> > > > On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev <
> > admitriev@gridgain.com
> > > >
> > > > wrote:
> > > >
> > > > > It looks like very useful and natural thing having the parameters
> > > change
> > > > on
> > > > > the fly.
> > > > > Maybe we should design something like OLCC (on-line configuration
> > > change)
> > > > > module, which will request different procedures for different bunch
> > of
> > > > > parameters.
> > > > > All the parameters, this way, will be splitted into several groups.
> > > > > For example in the worst case, when all the grid has to be
> > synchronized
> > > > for
> > > > > particular parameter change, some preparation on the grid has to be
> > > > > performed, than when all the nodes reports readiness, the parameter
> > > > change
> > > > > could be initiated.
> > > > > On the opposite if it is parameter configured per node, OLCC state
> > > > machine
> > > > > will work simpler without inter-node communication.
> > > > >
> > > > > On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <
> yzhdanov@apache.org>
> > > > > wrote:
> > > > >
> > > > > > >I see your point. In this case, we should have a special package
> > > > > > containing
> > > > > > >all the runtime config properties.
> > > > > >
> > > > > > Dmitry, I think this will be a mess.
> > > > > >
> > > > > > Igniters, any more opinions?
> > > > > >
> > > > > > --Yakov
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alexey Dmitriev, VP Engineering
> > > > > *GridGain Systems*
> > > > > www.gridgain.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Dmitriev, VP Engineering
> > > *GridGain Systems*
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Alexey Dmitriev, VP Engineering
> *GridGain Systems*
> www.gridgain.com
>
Re: Ignite: configuration changes at runtime
Posted by Alexey Dmitriev <ad...@gridgain.com>.
I believe it should be persistent.
We can have a parameter about "reset configuration on restart", which can
be also OLCC-compatible
On Mon, Aug 21, 2017 at 5:22 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev <ad...@gridgain.com>
> wrote:
>
> > I would say it should as soon as we moving to "persistence".
> > It will require to look at the things a bit different than before, but I
> > would say that's an evolution for the product.
> > We probably also should think how our configuration system should be
> > changed to make it more obvious.
> >
>
> But in that case, what to do with XML configuration? Should it be updated
> as well? Or even worse, what if user added configuration from code?
>
> On Mon, Aug 21, 2017 at 5:11 PM, Dmitriy Setrakyan <ds...@apache.org>
> > wrote:
> >
> > > I think the main question I have is whether this configuration change
> > will
> > > survive restarts. Part of me says it should, and the other part says it
> > > shouldn't.
> > >
> > > Does anyone have a strong opinion about this?
> > >
> > > D.
> > >
> > > On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev <
> admitriev@gridgain.com
> > >
> > > wrote:
> > >
> > > > It looks like very useful and natural thing having the parameters
> > change
> > > on
> > > > the fly.
> > > > Maybe we should design something like OLCC (on-line configuration
> > change)
> > > > module, which will request different procedures for different bunch
> of
> > > > parameters.
> > > > All the parameters, this way, will be splitted into several groups.
> > > > For example in the worst case, when all the grid has to be
> synchronized
> > > for
> > > > particular parameter change, some preparation on the grid has to be
> > > > performed, than when all the nodes reports readiness, the parameter
> > > change
> > > > could be initiated.
> > > > On the opposite if it is parameter configured per node, OLCC state
> > > machine
> > > > will work simpler without inter-node communication.
> > > >
> > > > On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <yz...@apache.org>
> > > > wrote:
> > > >
> > > > > >I see your point. In this case, we should have a special package
> > > > > containing
> > > > > >all the runtime config properties.
> > > > >
> > > > > Dmitry, I think this will be a mess.
> > > > >
> > > > > Igniters, any more opinions?
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Dmitriev, VP Engineering
> > > > *GridGain Systems*
> > > > www.gridgain.com
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Dmitriev, VP Engineering
> > *GridGain Systems*
> > www.gridgain.com
> >
>
--
Alexey Dmitriev, VP Engineering
*GridGain Systems*
www.gridgain.com
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Aug 21, 2017 at 7:25 AM, Alexey Kukushkin <kukushkinalexey@gmail.com
> wrote:
> I would vote for not automatically persisting runtime configuration
> changes. Still it makes sense to expose a "save(fileName)" method to allow
> explicitly saving changes to a different or same config file.
>
I like this better. We should give user an ability to save the updated
configuration into a file.
>
> On Mon, Aug 21, 2017 at 5:22 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev <admitriev@gridgain.com
> >
> > wrote:
> >
> > > I would say it should as soon as we moving to "persistence".
> > > It will require to look at the things a bit different than before, but
> I
> > > would say that's an evolution for the product.
> > > We probably also should think how our configuration system should be
> > > changed to make it more obvious.
> > >
> >
> > But in that case, what to do with XML configuration? Should it be updated
> > as well? Or even worse, what if user added configuration from code?
> >
> > On Mon, Aug 21, 2017 at 5:11 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > > wrote:
> > >
> > > > I think the main question I have is whether this configuration change
> > > will
> > > > survive restarts. Part of me says it should, and the other part says
> it
> > > > shouldn't.
> > > >
> > > > Does anyone have a strong opinion about this?
> > > >
> > > > D.
> > > >
> > > > On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev <
> > admitriev@gridgain.com
> > > >
> > > > wrote:
> > > >
> > > > > It looks like very useful and natural thing having the parameters
> > > change
> > > > on
> > > > > the fly.
> > > > > Maybe we should design something like OLCC (on-line configuration
> > > change)
> > > > > module, which will request different procedures for different bunch
> > of
> > > > > parameters.
> > > > > All the parameters, this way, will be splitted into several groups.
> > > > > For example in the worst case, when all the grid has to be
> > synchronized
> > > > for
> > > > > particular parameter change, some preparation on the grid has to be
> > > > > performed, than when all the nodes reports readiness, the parameter
> > > > change
> > > > > could be initiated.
> > > > > On the opposite if it is parameter configured per node, OLCC state
> > > > machine
> > > > > will work simpler without inter-node communication.
> > > > >
> > > > > On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <
> yzhdanov@apache.org>
> > > > > wrote:
> > > > >
> > > > > > >I see your point. In this case, we should have a special package
> > > > > > containing
> > > > > > >all the runtime config properties.
> > > > > >
> > > > > > Dmitry, I think this will be a mess.
> > > > > >
> > > > > > Igniters, any more opinions?
> > > > > >
> > > > > > --Yakov
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alexey Dmitriev, VP Engineering
> > > > > *GridGain Systems*
> > > > > www.gridgain.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Dmitriev, VP Engineering
> > > *GridGain Systems*
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Best regards,
> Alexey
>
Re: Ignite: configuration changes at runtime
Posted by Alexey Kukushkin <ku...@gmail.com>.
I would vote for not automatically persisting runtime configuration
changes. Still it makes sense to expose a "save(fileName)" method to allow
explicitly saving changes to a different or same config file.
On Mon, Aug 21, 2017 at 5:22 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev <ad...@gridgain.com>
> wrote:
>
> > I would say it should as soon as we moving to "persistence".
> > It will require to look at the things a bit different than before, but I
> > would say that's an evolution for the product.
> > We probably also should think how our configuration system should be
> > changed to make it more obvious.
> >
>
> But in that case, what to do with XML configuration? Should it be updated
> as well? Or even worse, what if user added configuration from code?
>
> On Mon, Aug 21, 2017 at 5:11 PM, Dmitriy Setrakyan <ds...@apache.org>
> > wrote:
> >
> > > I think the main question I have is whether this configuration change
> > will
> > > survive restarts. Part of me says it should, and the other part says it
> > > shouldn't.
> > >
> > > Does anyone have a strong opinion about this?
> > >
> > > D.
> > >
> > > On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev <
> admitriev@gridgain.com
> > >
> > > wrote:
> > >
> > > > It looks like very useful and natural thing having the parameters
> > change
> > > on
> > > > the fly.
> > > > Maybe we should design something like OLCC (on-line configuration
> > change)
> > > > module, which will request different procedures for different bunch
> of
> > > > parameters.
> > > > All the parameters, this way, will be splitted into several groups.
> > > > For example in the worst case, when all the grid has to be
> synchronized
> > > for
> > > > particular parameter change, some preparation on the grid has to be
> > > > performed, than when all the nodes reports readiness, the parameter
> > > change
> > > > could be initiated.
> > > > On the opposite if it is parameter configured per node, OLCC state
> > > machine
> > > > will work simpler without inter-node communication.
> > > >
> > > > On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <yz...@apache.org>
> > > > wrote:
> > > >
> > > > > >I see your point. In this case, we should have a special package
> > > > > containing
> > > > > >all the runtime config properties.
> > > > >
> > > > > Dmitry, I think this will be a mess.
> > > > >
> > > > > Igniters, any more opinions?
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Dmitriev, VP Engineering
> > > > *GridGain Systems*
> > > > www.gridgain.com
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Dmitriev, VP Engineering
> > *GridGain Systems*
> > www.gridgain.com
> >
>
--
Best regards,
Alexey
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev <ad...@gridgain.com>
wrote:
> I would say it should as soon as we moving to "persistence".
> It will require to look at the things a bit different than before, but I
> would say that's an evolution for the product.
> We probably also should think how our configuration system should be
> changed to make it more obvious.
>
But in that case, what to do with XML configuration? Should it be updated
as well? Or even worse, what if user added configuration from code?
On Mon, Aug 21, 2017 at 5:11 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > I think the main question I have is whether this configuration change
> will
> > survive restarts. Part of me says it should, and the other part says it
> > shouldn't.
> >
> > Does anyone have a strong opinion about this?
> >
> > D.
> >
> > On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev <admitriev@gridgain.com
> >
> > wrote:
> >
> > > It looks like very useful and natural thing having the parameters
> change
> > on
> > > the fly.
> > > Maybe we should design something like OLCC (on-line configuration
> change)
> > > module, which will request different procedures for different bunch of
> > > parameters.
> > > All the parameters, this way, will be splitted into several groups.
> > > For example in the worst case, when all the grid has to be synchronized
> > for
> > > particular parameter change, some preparation on the grid has to be
> > > performed, than when all the nodes reports readiness, the parameter
> > change
> > > could be initiated.
> > > On the opposite if it is parameter configured per node, OLCC state
> > machine
> > > will work simpler without inter-node communication.
> > >
> > > On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <yz...@apache.org>
> > > wrote:
> > >
> > > > >I see your point. In this case, we should have a special package
> > > > containing
> > > > >all the runtime config properties.
> > > >
> > > > Dmitry, I think this will be a mess.
> > > >
> > > > Igniters, any more opinions?
> > > >
> > > > --Yakov
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Dmitriev, VP Engineering
> > > *GridGain Systems*
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Alexey Dmitriev, VP Engineering
> *GridGain Systems*
> www.gridgain.com
>
Re: Ignite: configuration changes at runtime
Posted by Alexey Dmitriev <ad...@gridgain.com>.
I would say it should as soon as we moving to "persistence".
It will require to look at the things a bit different than before, but I
would say that's an evolution for the product.
We probably also should think how our configuration system should be
changed to make it more obvious.
On Mon, Aug 21, 2017 at 5:11 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> I think the main question I have is whether this configuration change will
> survive restarts. Part of me says it should, and the other part says it
> shouldn't.
>
> Does anyone have a strong opinion about this?
>
> D.
>
> On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev <ad...@gridgain.com>
> wrote:
>
> > It looks like very useful and natural thing having the parameters change
> on
> > the fly.
> > Maybe we should design something like OLCC (on-line configuration change)
> > module, which will request different procedures for different bunch of
> > parameters.
> > All the parameters, this way, will be splitted into several groups.
> > For example in the worst case, when all the grid has to be synchronized
> for
> > particular parameter change, some preparation on the grid has to be
> > performed, than when all the nodes reports readiness, the parameter
> change
> > could be initiated.
> > On the opposite if it is parameter configured per node, OLCC state
> machine
> > will work simpler without inter-node communication.
> >
> > On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <yz...@apache.org>
> > wrote:
> >
> > > >I see your point. In this case, we should have a special package
> > > containing
> > > >all the runtime config properties.
> > >
> > > Dmitry, I think this will be a mess.
> > >
> > > Igniters, any more opinions?
> > >
> > > --Yakov
> > >
> >
> >
> >
> > --
> > Alexey Dmitriev, VP Engineering
> > *GridGain Systems*
> > www.gridgain.com
> >
>
--
Alexey Dmitriev, VP Engineering
*GridGain Systems*
www.gridgain.com
Re: Ignite: configuration changes at runtime
Posted by Yakov Zhdanov <yz...@apache.org>.
>I think the main question I have is whether this configuration change will
>survive restarts. Part of me says it should, and the other part says it
>shouldn't.
Dmitry,
I think that configuration changes should survive restarts if persistence
is enabled. Moreover, newly joining nodes should get the current settings
of the running nodes.
--Yakov
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
I think the main question I have is whether this configuration change will
survive restarts. Part of me says it should, and the other part says it
shouldn't.
Does anyone have a strong opinion about this?
D.
On Mon, Aug 21, 2017 at 7:07 AM, Alexey Dmitriev <ad...@gridgain.com>
wrote:
> It looks like very useful and natural thing having the parameters change on
> the fly.
> Maybe we should design something like OLCC (on-line configuration change)
> module, which will request different procedures for different bunch of
> parameters.
> All the parameters, this way, will be splitted into several groups.
> For example in the worst case, when all the grid has to be synchronized for
> particular parameter change, some preparation on the grid has to be
> performed, than when all the nodes reports readiness, the parameter change
> could be initiated.
> On the opposite if it is parameter configured per node, OLCC state machine
> will work simpler without inter-node communication.
>
> On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <yz...@apache.org>
> wrote:
>
> > >I see your point. In this case, we should have a special package
> > containing
> > >all the runtime config properties.
> >
> > Dmitry, I think this will be a mess.
> >
> > Igniters, any more opinions?
> >
> > --Yakov
> >
>
>
>
> --
> Alexey Dmitriev, VP Engineering
> *GridGain Systems*
> www.gridgain.com
>
Re: Ignite: configuration changes at runtime
Posted by Alexey Dmitriev <ad...@gridgain.com>.
It looks like very useful and natural thing having the parameters change on
the fly.
Maybe we should design something like OLCC (on-line configuration change)
module, which will request different procedures for different bunch of
parameters.
All the parameters, this way, will be splitted into several groups.
For example in the worst case, when all the grid has to be synchronized for
particular parameter change, some preparation on the grid has to be
performed, than when all the nodes reports readiness, the parameter change
could be initiated.
On the opposite if it is parameter configured per node, OLCC state machine
will work simpler without inter-node communication.
On Mon, Aug 21, 2017 at 4:21 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> >I see your point. In this case, we should have a special package
> containing
> >all the runtime config properties.
>
> Dmitry, I think this will be a mess.
>
> Igniters, any more opinions?
>
> --Yakov
>
--
Alexey Dmitriev, VP Engineering
*GridGain Systems*
www.gridgain.com
Re: Ignite: configuration changes at runtime
Posted by Yakov Zhdanov <yz...@apache.org>.
>I see your point. In this case, we should have a special package containing
>all the runtime config properties.
Dmitry, I think this will be a mess.
Igniters, any more opinions?
--Yakov
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Aug 18, 2017 at 1:57 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> Here is the list of params that can be changed - https://cwiki.apache.org/
> confluence/display/IGNITE/Allow+Configuration+Settings+Change+At+Runtime
>
> >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.
>
> Again, how you provide all-in-one-place current node configuration? Also,
> why changes should be lost? In case of persistence they should not be lost,
> moreover, nodes joining with previous configuration should pick up current
> properties of running nodes.
>
I see your point. In this case, we should have a special package containing
all the runtime config properties.
>
> >I think providing API is important for users who want to integrate Ignite
> >with their own management tools.
>
> This maybe done via JMX. Currently, I guess we expose only configuration
> toString() via it.
>
All the SomethingConfigRuintime interfaces should be exposed via JMX
Re: Ignite: configuration changes at runtime
Posted by Yakov Zhdanov <yz...@apache.org>.
Here is the list of params that can be changed - https://cwiki.apache.org/
confluence/display/IGNITE/Allow+Configuration+Settings+Change+At+Runtime
>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.
Again, how you provide all-in-one-place current node configuration? Also,
why changes should be lost? In case of persistence they should not be lost,
moreover, nodes joining with previous configuration should pick up current
properties of running nodes.
>I think providing API is important for users who want to integrate Ignite
>with their own management tools.
This maybe done via JMX. Currently, I guess we expose only configuration
toString() via it.
--Yakov
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, Aug 17, 2017 at 10:37 AM, Yakov Zhdanov <yz...@apache.org> 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
>
Re: Ignite: configuration changes at runtime
Posted by Yakov Zhdanov <yz...@apache.org>.
>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.
1. I would not mess with propagation for now. Propagation can be handled by
special methods or by Visor/WebConsole
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).
>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?
--Yakov
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Yakov,
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.
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.
D.
On Tue, Aug 15, 2017 at 3:20 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> > I like the idea, but I am not sure how we will separate properties that
> are
> >dynamically changeable from the constant ones.
>
> Why do you want the separation? I thought having some annotation like
> @RuntimeChangeSupported will be sufficient for documentation
>
> >Also, what is the API for updating these properties? Perhaps we can create
> >a special interface, e.g. IgniteConfigurationRuntime (similar to Java
> >Runtime class), which will have only setters and have all the properties
> >that can be changed at runtime.
>
> The best way is to change the properties where they are configured, i.e.
> use setters of configuration objects and setters of SPI's, etc. This most
> likely will require stop using copy constructors for configurations. I
> never liked that since it was sometimes the reason for stupid issues and we
> do not do deep copy, e.g. SPIs and user provided factories are moved to the
> copy as is. Moreover it is not 100% clear why it works this way for ages?
>
> I don't like separate interfaces with setters. How then should I get the
> current updated values? Let's start from shorter list of easy to support
> properties and see what issues we face.
>
> We also need to think over the propagation to newly started nodes. If new
> nodes are started with a config file and some properties were updated at
> runtime for current server topology.
>
> --Yakov
>
Re: Ignite: configuration changes at runtime
Posted by Yakov Zhdanov <yz...@apache.org>.
> I like the idea, but I am not sure how we will separate properties that
are
>dynamically changeable from the constant ones.
Why do you want the separation? I thought having some annotation like
@RuntimeChangeSupported will be sufficient for documentation
>Also, what is the API for updating these properties? Perhaps we can create
>a special interface, e.g. IgniteConfigurationRuntime (similar to Java
>Runtime class), which will have only setters and have all the properties
>that can be changed at runtime.
The best way is to change the properties where they are configured, i.e.
use setters of configuration objects and setters of SPI's, etc. This most
likely will require stop using copy constructors for configurations. I
never liked that since it was sometimes the reason for stupid issues and we
do not do deep copy, e.g. SPIs and user provided factories are moved to the
copy as is. Moreover it is not 100% clear why it works this way for ages?
I don't like separate interfaces with setters. How then should I get the
current updated values? Let's start from shorter list of easy to support
properties and see what issues we face.
We also need to think over the propagation to newly started nodes. If new
nodes are started with a config file and some properties were updated at
runtime for current server topology.
--Yakov
Re: Ignite: configuration changes at runtime
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Yakov,
I like the idea, but I am not sure how we will separate properties that are
dynamically changeable from the constant ones.
Also, what is the API for updating these properties? Perhaps we can create
a special interface, e.g. IgniteConfigurationRuntime (similar to Java
Runtime class), which will have only setters and have all the properties
that can be changed at runtime.
D.
On Fri, Aug 11, 2017 at 8:49 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> Hello Igniters!
>
> I want to start a discussion on a pretty useful feature that will help us
> to bring Ignite's usability to the next level. How about supporting changes
> to (some) configuration at runtime? Currently, most of the config props are
> carved in stone and will require node restart for a change.
>
> On this page I tried to summarize the vision and put the most important
> properties (from my perspective) that will be handy to change at runtime:
> https://cwiki.apache.org/confluence/display/IGNITE/
> Allow+Configuration+Settings+Change+At+Runtime
>
> Alex Goncharuk, can you please help to fill in the suggestions for
> persistence and memory config?
>
> After we agree on properties list then I will file a ticket to implement
> mechanism for properties propagation (via custom event or via ordinary
> communication) and tickets for each Ignite's configuration bean and SPIs.
>
> Comments are welcome.
>
> --Yakov
>