Clusterwide settings validation

[Andrew Medvedev]

Hello everybody

Our company has lots of nodes in cluster, and we have seen some
problems with inconsistent settings on nodes clusterwide. To help us
with this, we made an utility to check consistency of settings on
running cluster, but it is a hack, better ways seems to be settings
validation by each node itself on start/joining topology/etc..

1) Is his needed?
2) Have the implementation details been discussed somewhere?

Cheers

[Nikolay Izhikov-2]

Hello, Andrew.

Can you clarify your question?

What checks do you mean, exactly?
Do you mean internal Ignite checks or user-provided checks?

Ignite checks configuration consistency on node start [1].

Ignite do have consistency check for a joining node. Take a look at [2] and all of it children.

[1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
[2] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153

В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:

> Hello everybody
>
> Our company has lots of nodes in cluster, and we have seen some
> problems with inconsistent settings on nodes clusterwide. To help us
> with this, we made an utility to check consistency of settings on
> running cluster, but it is a hack, better ways seems to be settings
> validation by each node itself on start/joining topology/etc..
>
> 1) Is his needed?
> 2) Have the implementation details been discussed somewhere?
>
> Cheers

[Andrew Medvedev]

Hi Nikolay

No, we have been beaten by
https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%22rebalanceThreadPoolSize%22
it is not checked on start

Utility I mean check
org.apache.ignite.configuration.IgniteConfiguration and children

On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov <[hidden email]> wrote:

> Hello, Andrew.
>
> Can you clarify your question?
>
> What checks do you mean, exactly?
> Do you mean internal Ignite checks or user-provided checks?
>
> Ignite checks configuration consistency on node start [1].
>
> Ignite do have consistency check for a joining node. Take a look at [2] and all of it children.
>
> [1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
> [2] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
>
> В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
>> Hello everybody
>>
>> Our company has lots of nodes in cluster, and we have seen some
>> problems with inconsistent settings on nodes clusterwide. To help us
>> with this, we made an utility to check consistency of settings on
>> running cluster, but it is a hack, better ways seems to be settings
>> validation by each node itself on start/joining topology/etc..
>>
>> 1) Is his needed?
>> 2) Have the implementation details been discussed somewhere?
>>
>> Cheers

[Yakov Zhdanov-2]

Guys, I created ticket for config params validation -
https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to comment.

Yakov Zhdanov
www.gridgain.com

2018-07-04 10:51 GMT+03:00 Andrew Medvedev <[hidden email]>:

> Hi Nikolay
>
> No, we have been beaten by
> <a href="https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%">https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
> 22rebalanceThreadPoolSize%22
> it is not checked on start
>
> Utility I mean check
> org.apache.ignite.configuration.IgniteConfiguration and children
>
> On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov <[hidden email]>
> wrote:
> > Hello, Andrew.
> >
> > Can you clarify your question?
> >
> > What checks do you mean, exactly?
> > Do you mean internal Ignite checks or user-provided checks?
> >
> > Ignite checks configuration consistency on node start [1].
> >
> > Ignite do have consistency check for a joining node. Take a look at [2]
> and all of it children.
> >
> > [1] https://github.com/apache/ignite/blob/master/modules/
> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
> > [2] https://github.com/apache/ignite/blob/master/modules/
> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
> >
> > В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
> >> Hello everybody
> >>
> >> Our company has lots of nodes in cluster, and we have seen some
> >> problems with inconsistent settings on nodes clusterwide. To help us
> >> with this, we made an utility to check consistency of settings on
> >> running cluster, but it is a hack, better ways seems to be settings
> >> validation by each node itself on start/joining topology/etc..
> >>
> >> 1) Is his needed?
> >> 2) Have the implementation details been discussed somewhere?
> >>
> >> Cheers
>

[Andrew Medvedev]

Made comment there, c&p here as well

Is it going to be a preconfigured set of  settings, or a whole range
of settings?

If latter :

1) Property names in CacheConfiguration do not always correspond to
getters (some follow different naming conventions, some are completely
different, as in memPlcName and getDataRegionName()), so inclusion
pattern ("get all properties") does not work quite well with them

2) If using manual handling of getter methods, we see that a lot of
metrics are returned by methods in CacheConfiguration and below,
instead of properties (in TcpCommunicationSpi especially), and getter
methods are not properly annotated. (for ex see
https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
pattern ("get all except metrics etc") forces us to manually exclude
those, not quite well too, looks like a hack

Plus some properties, although configurable, have their defaults
dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE

Just to make sure, we compare with coordinator, log locally, and
client nodes are excluded?

On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov <[hidden email]> wrote:

> Guys, I created ticket for config params validation -
> https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to comment.
>
> Yakov Zhdanov
> www.gridgain.com
>
> 2018-07-04 10:51 GMT+03:00 Andrew Medvedev <[hidden email]>:
>
>> Hi Nikolay
>>
>> No, we have been beaten by
>> <a href="https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%">https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
>> 22rebalanceThreadPoolSize%22
>> it is not checked on start
>>
>> Utility I mean check
>> org.apache.ignite.configuration.IgniteConfiguration and children
>>
>> On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov <[hidden email]>
>> wrote:
>> > Hello, Andrew.
>> >
>> > Can you clarify your question?
>> >
>> > What checks do you mean, exactly?
>> > Do you mean internal Ignite checks or user-provided checks?
>> >
>> > Ignite checks configuration consistency on node start [1].
>> >
>> > Ignite do have consistency check for a joining node. Take a look at [2]
>> and all of it children.
>> >
>> > [1] https://github.com/apache/ignite/blob/master/modules/
>> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
>> > [2] https://github.com/apache/ignite/blob/master/modules/
>> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
>> >
>> > В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
>> >> Hello everybody
>> >>
>> >> Our company has lots of nodes in cluster, and we have seen some
>> >> problems with inconsistent settings on nodes clusterwide. To help us
>> >> with this, we made an utility to check consistency of settings on
>> >> running cluster, but it is a hack, better ways seems to be settings
>> >> validation by each node itself on start/joining topology/etc..
>> >>
>> >> 1) Is his needed?
>> >> 2) Have the implementation details been discussed somewhere?
>> >>
>> >> Cheers
>>

[Ivan Rakov]

Guys,

For your information: rebalanceThreadPoolSize validation is already
implemented and merged to master:
https://issues.apache.org/jira/browse/IGNITE-8904
You can overview the commit to see the approach. By the way, we already
validate some other parameters that can't differ among cluster nodes
(page size, tx configuration): GridCacheProcessor#checkConsistency.
We also match necessary part of CacheConfiguration between nodes in
GridCacheUtils#checkAttributeMismatch method.

Does anyone know another properties mismatch of which can backfire on us?

Best Regards,
Ivan Rakov

On 10.07.2018 10:47, Andrew Medvedev wrote:

> Made comment there, c&p here as well
>
> Is it going to be a preconfigured set of  settings, or a whole range
> of settings?
>
> If latter :
>
> 1) Property names in CacheConfiguration do not always correspond to
> getters (some follow different naming conventions, some are completely
> different, as in memPlcName and getDataRegionName()), so inclusion
> pattern ("get all properties") does not work quite well with them
>
> 2) If using manual handling of getter methods, we see that a lot of
> metrics are returned by methods in CacheConfiguration and below,
> instead of properties (in TcpCommunicationSpi especially), and getter
> methods are not properly annotated. (for ex see
> https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
> pattern ("get all except metrics etc") forces us to manually exclude
> those, not quite well too, looks like a hack
>
> Plus some properties, although configurable, have their defaults
> dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE
>
> Just to make sure, we compare with coordinator, log locally, and
> client nodes are excluded?
>
> On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov <[hidden email]> wrote:
>> Guys, I created ticket for config params validation -
>> https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to comment.
>>
>> Yakov Zhdanov
>> www.gridgain.com
>>
>> 2018-07-04 10:51 GMT+03:00 Andrew Medvedev <[hidden email]>:
>>
>>> Hi Nikolay
>>>
>>> No, we have been beaten by
>>> <a href="https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%">https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
>>> 22rebalanceThreadPoolSize%22
>>> it is not checked on start
>>>
>>> Utility I mean check
>>> org.apache.ignite.configuration.IgniteConfiguration and children
>>>
>>> On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov <[hidden email]>
>>> wrote:
>>>> Hello, Andrew.
>>>>
>>>> Can you clarify your question?
>>>>
>>>> What checks do you mean, exactly?
>>>> Do you mean internal Ignite checks or user-provided checks?
>>>>
>>>> Ignite checks configuration consistency on node start [1].
>>>>
>>>> Ignite do have consistency check for a joining node. Take a look at [2]
>>> and all of it children.
>>>> [1] https://github.com/apache/ignite/blob/master/modules/
>>> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
>>>> [2] https://github.com/apache/ignite/blob/master/modules/
>>> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
>>>> В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
>>>>> Hello everybody
>>>>>
>>>>> Our company has lots of nodes in cluster, and we have seen some
>>>>> problems with inconsistent settings on nodes clusterwide. To help us
>>>>> with this, we made an utility to check consistency of settings on
>>>>> running cluster, but it is a hack, better ways seems to be settings
>>>>> validation by each node itself on start/joining topology/etc..
>>>>>
>>>>> 1) Is his needed?
>>>>> 2) Have the implementation details been discussed somewhere?
>>>>>
>>>>> Cheers

[yzhdanov]

Ivan, I would think of some test that will randomly generate configs for
nodes and run some logic.

--Yakov

[slava.koptilin]

.Hello Ivan,

I think it would be nice to add validation
DataRegionConfiguration#persistenceEnabled property. That property must be
the same across a cluster for the given data region.
Perhaps, different values of `initSize`, `maxSize` etc make sense in case
of a heterogeneous cluster, except  `persistenceEnabled`

Thanks,
S.

вт, 10 июл. 2018 г. в 13:42, Ivan Rakov <[hidden email]>:

> Guys,
>
> For your information: rebalanceThreadPoolSize validation is already
> implemented and merged to master:
> https://issues.apache.org/jira/browse/IGNITE-8904
> You can overview the commit to see the approach. By the way, we already
> validate some other parameters that can't differ among cluster nodes
> (page size, tx configuration): GridCacheProcessor#checkConsistency.
> We also match necessary part of CacheConfiguration between nodes in
> GridCacheUtils#checkAttributeMismatch method.
>
> Does anyone know another properties mismatch of which can backfire on us?
>
> Best Regards,
> Ivan Rakov
>
> On 10.07.2018 10:47, Andrew Medvedev wrote:
> > Made comment there, c&p here as well
> >
> > Is it going to be a preconfigured set of  settings, or a whole range
> > of settings?
> >
> > If latter :
> >
> > 1) Property names in CacheConfiguration do not always correspond to
> > getters (some follow different naming conventions, some are completely
> > different, as in memPlcName and getDataRegionName()), so inclusion
> > pattern ("get all properties") does not work quite well with them
> >
> > 2) If using manual handling of getter methods, we see that a lot of
> > metrics are returned by methods in CacheConfiguration and below,
> > instead of properties (in TcpCommunicationSpi especially), and getter
> > methods are not properly annotated. (for ex see
> > https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
> > pattern ("get all except metrics etc") forces us to manually exclude
> > those, not quite well too, looks like a hack
> >
> > Plus some properties, although configurable, have their defaults
> > dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE
> >
> > Just to make sure, we compare with coordinator, log locally, and
> > client nodes are excluded?
> >
> > On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov <[hidden email]>
> wrote:
> >> Guys, I created ticket for config params validation -
> >> https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to
> comment.
> >>
> >> Yakov Zhdanov
> >> www.gridgain.com
> >>
> >> 2018-07-04 10:51 GMT+03:00 Andrew Medvedev <[hidden email]
> >:
> >>
> >>> Hi Nikolay
> >>>
> >>> No, we have been beaten by
> >>> <a href="https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%">https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
> >>> 22rebalanceThreadPoolSize%22
> >>> it is not checked on start
> >>>
> >>> Utility I mean check
> >>> org.apache.ignite.configuration.IgniteConfiguration and children
> >>>
> >>> On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov <[hidden email]>
> >>> wrote:
> >>>> Hello, Andrew.
> >>>>
> >>>> Can you clarify your question?
> >>>>
> >>>> What checks do you mean, exactly?
> >>>> Do you mean internal Ignite checks or user-provided checks?
> >>>>
> >>>> Ignite checks configuration consistency on node start [1].
> >>>>
> >>>> Ignite do have consistency check for a joining node. Take a look at
> [2]
> >>> and all of it children.
> >>>> [1] https://github.com/apache/ignite/blob/master/modules/
> >>> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
> >>>> [2] https://github.com/apache/ignite/blob/master/modules/
> >>> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
> >>>> В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
> >>>>> Hello everybody
> >>>>>
> >>>>> Our company has lots of nodes in cluster, and we have seen some
> >>>>> problems with inconsistent settings on nodes clusterwide. To help us
> >>>>> with this, we made an utility to check consistency of settings on
> >>>>> running cluster, but it is a hack, better ways seems to be settings
> >>>>> validation by each node itself on start/joining topology/etc..
> >>>>>
> >>>>> 1) Is his needed?
> >>>>> 2) Have the implementation details been discussed somewhere?
> >>>>>
> >>>>> Cheers
>
>

[Ivan Rakov]

Slava,

I agree. Different persistence enabled flag can cause unpleasant issues.
I've left a comment in IGNITE-8951.

Yakov,

Seems like I misunderstood the point of the discussion from the very
beginning. I thought that Andrew raised topic to discuss adding new
checks that will fail node join (like we do for different page size and
rebalance pool size). If we are talking about /printing
warnin//gs//about all differences/, we indeed can start with logic that
passes through configuration classes with reflection. As a next step, we
can filter out the properties that are expected to be different
(consistentId, etc). I believe, full list of such properties can't be
collected without manual research.

Best Regards,
Ivan Rakov

On 10.07.2018 14:06, Вячеслав Коптилин wrote:

> .Hello Ivan,
>
> I think it would be nice to add validation
> DataRegionConfiguration#persistenceEnabled property. That property must be
> the same across a cluster for the given data region.
> Perhaps, different values of `initSize`, `maxSize` etc make sense in case
> of a heterogeneous cluster, except  `persistenceEnabled`
>
> Thanks,
> S.
>
> вт, 10 июл. 2018 г. в 13:42, Ivan Rakov <[hidden email]>:
>
>> Guys,
>>
>> For your information: rebalanceThreadPoolSize validation is already
>> implemented and merged to master:
>> https://issues.apache.org/jira/browse/IGNITE-8904
>> You can overview the commit to see the approach. By the way, we already
>> validate some other parameters that can't differ among cluster nodes
>> (page size, tx configuration): GridCacheProcessor#checkConsistency.
>> We also match necessary part of CacheConfiguration between nodes in
>> GridCacheUtils#checkAttributeMismatch method.
>>
>> Does anyone know another properties mismatch of which can backfire on us?
>>
>> Best Regards,
>> Ivan Rakov
>>
>> On 10.07.2018 10:47, Andrew Medvedev wrote:
>>> Made comment there, c&p here as well
>>>
>>> Is it going to be a preconfigured set of  settings, or a whole range
>>> of settings?
>>>
>>> If latter :
>>>
>>> 1) Property names in CacheConfiguration do not always correspond to
>>> getters (some follow different naming conventions, some are completely
>>> different, as in memPlcName and getDataRegionName()), so inclusion
>>> pattern ("get all properties") does not work quite well with them
>>>
>>> 2) If using manual handling of getter methods, we see that a lot of
>>> metrics are returned by methods in CacheConfiguration and below,
>>> instead of properties (in TcpCommunicationSpi especially), and getter
>>> methods are not properly annotated. (for ex see
>>> https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
>>> pattern ("get all except metrics etc") forces us to manually exclude
>>> those, not quite well too, looks like a hack
>>>
>>> Plus some properties, although configurable, have their defaults
>>> dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE
>>>
>>> Just to make sure, we compare with coordinator, log locally, and
>>> client nodes are excluded?
>>>
>>> On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov <[hidden email]>
>> wrote:
>>>> Guys, I created ticket for config params validation -
>>>> https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to
>> comment.
>>>> Yakov Zhdanov
>>>> www.gridgain.com
>>>>
>>>> 2018-07-04 10:51 GMT+03:00 Andrew Medvedev <[hidden email]
>>> :
>>>>> Hi Nikolay
>>>>>
>>>>> No, we have been beaten by
>>>>> <a href="https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%">https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
>>>>> 22rebalanceThreadPoolSize%22
>>>>> it is not checked on start
>>>>>
>>>>> Utility I mean check
>>>>> org.apache.ignite.configuration.IgniteConfiguration and children
>>>>>
>>>>> On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov <[hidden email]>
>>>>> wrote:
>>>>>> Hello, Andrew.
>>>>>>
>>>>>> Can you clarify your question?
>>>>>>
>>>>>> What checks do you mean, exactly?
>>>>>> Do you mean internal Ignite checks or user-provided checks?
>>>>>>
>>>>>> Ignite checks configuration consistency on node start [1].
>>>>>>
>>>>>> Ignite do have consistency check for a joining node. Take a look at
>> [2]
>>>>> and all of it children.
>>>>>> [1] https://github.com/apache/ignite/blob/master/modules/
>>>>> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
>>>>>> [2] https://github.com/apache/ignite/blob/master/modules/
>>>>> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
>>>>>> В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
>>>>>>> Hello everybody
>>>>>>>
>>>>>>> Our company has lots of nodes in cluster, and we have seen some
>>>>>>> problems with inconsistent settings on nodes clusterwide. To help us
>>>>>>> with this, we made an utility to check consistency of settings on
>>>>>>> running cluster, but it is a hack, better ways seems to be settings
>>>>>>> validation by each node itself on start/joining topology/etc..
>>>>>>>
>>>>>>> 1) Is his needed?
>>>>>>> 2) Have the implementation details been discussed somewhere?
>>>>>>>
>>>>>>> Cheers
>>

[dsetrakyan]

What about an idea to have a validation template file (e.g.
ignite-validate.xml), and make sure on startup that all config properties
specified in that file match. This way a user could put this file somewhere
on a shared network drive and have an extra degree of confidence that the
configuration is valid.

Thoughts?

D.


On Tue, Jul 10, 2018 at 5:43 PM, Ivan Rakov <[hidden email]> wrote:

> Slava,
>
> I agree. Different persistence enabled flag can cause unpleasant issues.
> I've left a comment in IGNITE-8951.
>
> Yakov,
>
> Seems like I misunderstood the point of the discussion from the very
> beginning. I thought that Andrew raised topic to discuss adding new checks
> that will fail node join (like we do for different page size and rebalance
> pool size). If we are talking about /printing warnin//gs//about all
> differences/, we indeed can start with logic that passes through
> configuration classes with reflection. As a next step, we can filter out
> the properties that are expected to be different (consistentId, etc). I
> believe, full list of such properties can't be collected without manual
> research.
>
> Best Regards,
> Ivan Rakov
>
>
> On 10.07.2018 14:06, Вячеслав Коптилин wrote:
>
>> .Hello Ivan,
>>
>> I think it would be nice to add validation
>> DataRegionConfiguration#persistenceEnabled property. That property must
>> be
>> the same across a cluster for the given data region.
>> Perhaps, different values of `initSize`, `maxSize` etc make sense in case
>> of a heterogeneous cluster, except  `persistenceEnabled`
>>
>> Thanks,
>> S.
>>
>> вт, 10 июл. 2018 г. в 13:42, Ivan Rakov <[hidden email]>:
>>
>> Guys,
>>>
>>> For your information: rebalanceThreadPoolSize validation is already
>>> implemented and merged to master:
>>> https://issues.apache.org/jira/browse/IGNITE-8904
>>> You can overview the commit to see the approach. By the way, we already
>>> validate some other parameters that can't differ among cluster nodes
>>> (page size, tx configuration): GridCacheProcessor#checkConsistency.
>>> We also match necessary part of CacheConfiguration between nodes in
>>> GridCacheUtils#checkAttributeMismatch method.
>>>
>>> Does anyone know another properties mismatch of which can backfire on us?
>>>
>>> Best Regards,
>>> Ivan Rakov
>>>
>>> On 10.07.2018 10:47, Andrew Medvedev wrote:
>>>
>>>> Made comment there, c&p here as well
>>>>
>>>> Is it going to be a preconfigured set of  settings, or a whole range
>>>> of settings?
>>>>
>>>> If latter :
>>>>
>>>> 1) Property names in CacheConfiguration do not always correspond to
>>>> getters (some follow different naming conventions, some are completely
>>>> different, as in memPlcName and getDataRegionName()), so inclusion
>>>> pattern ("get all properties") does not work quite well with them
>>>>
>>>> 2) If using manual handling of getter methods, we see that a lot of
>>>> metrics are returned by methods in CacheConfiguration and below,
>>>> instead of properties (in TcpCommunicationSpi especially), and getter
>>>> methods are not properly annotated. (for ex see
>>>> https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
>>>> pattern ("get all except metrics etc") forces us to manually exclude
>>>> those, not quite well too, looks like a hack
>>>>
>>>> Plus some properties, although configurable, have their defaults
>>>> dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE
>>>>
>>>> Just to make sure, we compare with coordinator, log locally, and
>>>> client nodes are excluded?
>>>>
>>>> On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov <[hidden email]>
>>>>
>>> wrote:
>>>
>>>> Guys, I created ticket for config params validation -
>>>>> https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to
>>>>>
>>>> comment.
>>>
>>>> Yakov Zhdanov
>>>>> www.gridgain.com
>>>>>
>>>>> 2018-07-04 10:51 GMT+03:00 Andrew Medvedev <
>>>>> [hidden email]
>>>>>
>>>> :
>>>>
>>>>> Hi Nikolay
>>>>>>
>>>>>> No, we have been beaten by
>>>>>> <a href="https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%">https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
>>>>>> 22rebalanceThreadPoolSize%22
>>>>>> it is not checked on start
>>>>>>
>>>>>> Utility I mean check
>>>>>> org.apache.ignite.configuration.IgniteConfiguration and children
>>>>>>
>>>>>> On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov <[hidden email]
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>>> Hello, Andrew.
>>>>>>>
>>>>>>> Can you clarify your question?
>>>>>>>
>>>>>>> What checks do you mean, exactly?
>>>>>>> Do you mean internal Ignite checks or user-provided checks?
>>>>>>>
>>>>>>> Ignite checks configuration consistency on node start [1].
>>>>>>>
>>>>>>> Ignite do have consistency check for a joining node. Take a look at
>>>>>>>
>>>>>> [2]
>>>
>>>> and all of it children.
>>>>>>
>>>>>>> [1] https://github.com/apache/ignite/blob/master/modules/
>>>>>>>
>>>>>> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
>>>>>>
>>>>>>> [2] https://github.com/apache/ignite/blob/master/modules/
>>>>>>>
>>>>>> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
>>>>>>
>>>>>>> В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
>>>>>>>
>>>>>>>> Hello everybody
>>>>>>>>
>>>>>>>> Our company has lots of nodes in cluster, and we have seen some
>>>>>>>> problems with inconsistent settings on nodes clusterwide. To help us
>>>>>>>> with this, we made an utility to check consistency of settings on
>>>>>>>> running cluster, but it is a hack, better ways seems to be settings
>>>>>>>> validation by each node itself on start/joining topology/etc..
>>>>>>>>
>>>>>>>> 1) Is his needed?
>>>>>>>> 2) Have the implementation details been discussed somewhere?
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>
>>>
>

[yzhdanov]

Ivan, yes. We can go with reflection through configuration and SPIs and,
you are rigth, suppressed list should be manually defined.

--Yakov

[dsetrakyan]

BTW, I have added a ticket for the configuration template [1] and linked it
to the ticket originally created by Yakov [2].

[1] https://issues.apache.org/jira/browse/IGNITE-8986
[2] https://issues.apache.org/jira/browse/IGNITE-8951

D.

On Wed, Jul 11, 2018 at 6:58 PM, Yakov Zhdanov <[hidden email]> wrote:

> Ivan, yes. We can go with reflection through configuration and SPIs and,
> you are rigth, suppressed list should be manually defined.
>
> --Yakov
>