[
https://issues.apache.org/jira/browse/IGNITE-13837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17257002#comment-17257002
]
Ivan Bessonov commented on IGNITE-13837:
----------------------------------------
So, here's my train of thoughts before the new year:
regardless of configuration framework implementation we should have an
independent configuration subsystem that will provide:
* discovery configuration to get cluster information;
* local metastorage configuration to read stored values;
* distributed metastorage should be available to read cluster configuration as
well.
First of all, let's talk about local node configuration, that's easier. Is
there a necessity to give it the initial configuration that can't have default
values in principle? That's a hard question. I'd say that local "init"
configuration should not exist at all - we just reconfigure already started
node with existing API, that's it. BUT, even if it's required, it still can be
applied on started node.
I see it like a special mode, "limbo". Process is started, but most of
components are not. They're waiting for command. During this time "readonly"
configuration (like pool sizes) can be changed and applied later. How do we
achieve it - it's either Java API method call or command line tool command that
moves node to configured state.
So let me repeat - the idea is that when node is starting, it doesn't require
"init" configuration to be passed to it. We only read values from local
metastorage. And wait for some command it metastorage indicates clear new node.
Next is distributed configuration. Basic idea is the same, but with a broader
scope. When node is started, it gets distributed configuration and only then
declares itself as a part of topology, starting its components at the same
time. Node components must not start with outdated distributed configuration
values. I'm not sure about how absurdly strong this requirement should be,
maybe we shouldn't join node with outdated configuration and +force it to
invalidate its components, update configuration and try to start again+. It
would actually make sense.
New cluster will also be started in limbo state, but on a global scale. It'll
wait for "activation" or something. And only when cluster receives additional
command with every required configuration value, it'll become fully functional.
You know, this whole thing comes very close to the topic of upgrading to the
new version. I see it this way:
* you restart your cluster with updated Ignite 3.1, for example;
* cluster either waits for manual "new version activation" OR works like the
old Ignite 3.0 +until it receives all configuration values required for 3.1
features+.
I know that my ideas look kinda extreme, we should discuss them. Everything
that I wrote is tricky for implementation, I get it, this solution should be
compromised or simplified at least.
> Configuration initialization
> ----------------------------
>
> Key: IGNITE-13837
> URL: https://issues.apache.org/jira/browse/IGNITE-13837
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Kalashnikov
> Assignee: Ivan Bessonov
> Priority: Major
>
> It needs to think how the first initialization of node/cluster should look
> like. What is the format of initial properties(json/hocon etc.)? How should
> they be handled?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
