Ignite: configuration changes at runtime

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Ignite: configuration changes at runtime

yzhdanov
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignite: configuration changes at runtime

Alexey Kuznetsov
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignite: configuration changes at runtime

dsetrakyan
In reply to this post by yzhdanov
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignite: configuration changes at runtime

yzhdanov
In reply to this post by Alexey Kuznetsov
>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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignite: configuration changes at runtime

yzhdanov
In reply to this post by dsetrakyan
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignite: configuration changes at runtime

dsetrakyan
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignite: configuration changes at runtime

yzhdanov
>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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignite: configuration changes at runtime

dsetrakyan
On Thu, Aug 17, 2017 at 10:37 AM, Yakov Zhdanov <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignite: configuration changes at runtime

yzhdanov
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Ignite: configuration changes at runtime

Alexey Kuznetsov
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 <[hidden email]> 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
Loading...