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
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
On Tue, Aug 22, 2017 at 4:43 AM, Yakov Zhdanov 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
>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
>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
On Mon, Aug 21, 2017 at 6:20 PM, Alexey Kuznetsov
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
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
wrote:
> On Mon, Aug 21, 2017 at 7:28 AM, Alexey Dmitriev
On Mon, Aug 21, 2017 at 7:28 AM, Alexey Dmitriev
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
On Mon, Aug 21, 2017 at 7:25 AM, Alexey Kukushkin 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 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
wrote:
> On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev
>
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
wrote:
> On Mon,
On Mon, Aug 21, 2017 at 7:15 AM, Alexey Dmitriev
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
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
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
wrote:
> It
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
>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
On Fri, Aug 18, 2017 at 1:57 AM, Yakov Zhdanov 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.
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
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
On Thu, Aug 17, 2017 at 10:37 AM, Yakov Zhdanov 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
>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
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
> 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
>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
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
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
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
27 matches
Mail list logo