[jira] [Comment Edited] (IGNITE-8951) Need to validate nodes configuration across cluster and warn on different parameters value

["Andrew Medvedev (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16536678#comment-16536678 ] 

Andrew Medvedev edited comment on IGNITE-8951 at 7/9/18 8:53 AM:
-----------------------------------------------------------------

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

If latter, we made a tool to get properties via reflection and here are some things to consider:

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, so better understanding of what should be checked and with what LOG level is welcome.

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


was (Author: andmed):
Is it going to be a set of preconfigured settings, or a whole range of settings?

If latter, we made a tool to get properties via reflection and here are some things to consider:

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, so better understanding of what should be checked and with what LOG level is welcome.

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

> Need to validate nodes configuration across cluster and warn on different parameters value
> ------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-8951
>                 URL: https://issues.apache.org/jira/browse/IGNITE-8951
>             Project: Ignite
>          Issue Type: Task
>            Reporter: Yakov Zhdanov
>            Priority: Major
>
> On node start, node should output in its logs the  list of parameters havnig values different from values on remote node. This should be skipped for parameters that are always different e.g. host name, node ID or IP, however should be an option to include parameters from default ignore list as well.
> Another requrement is that the intended output may be fully supressed by setting sysmem property -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true
> It seems that the implementation approach should be similar to performance suggestions Ignite currently has.
> The output may be as following
> {noformat}
> Local node has different configuration comparted to remote nodes for paramenters (fix if possible). To disable, set -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true
>   ^-- rebalanceThreadPoolSize [locNodeVal=4, rmtNodeId=X1X1, rmtNodeVal=8]
>   ^-- commSpi.selectorsCnt [locNodeVal=2, rmtNodeId=Y1Y1, rmtNodeVal=4]
>   ^-- commSpi.selectorsCnt [locNodeVal=2, rmtNodeId=Z1Z1, rmtNodeVal=8]
> {noformat}
> All components should add messages to {{cfgConsistencyRegister}} on startup and then all differences should be output in one step.
> If node aborts startup due to any problem differences collected so far should be output to logs.
> If there are more than 1 value for some config parameter among remote nodes then all distinct options should be output (see {{commSpi.selectorsCnt}} in the example above).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)