[
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)
