...
ID | IEP-81 | ||||||||
Author | |||||||||
Sponsor | |||||||||
Created |
| ||||||||
Status |
|
Table of Contents |
---|
The IEP is intended to eliminate all the current limitations with cluster management and provide additional features which may be available out of the boxsimplify, standardise, unifies development of Ignite management commands by providing declarative API for arguments and unified command invokers via various protocols - CLI, JMX, REST.
All of Ignite Cluster management operations are presented as running compute tasks over the cluster. Depending on the management operation required to be executed some of the tasks are running on a single Ignite node only or performing full compute operation overall cluster nodes with reducing the computation result on the originating node.
...
Without handlers and abstractions mentioned above, a new management task won't be available for a user even if it persists in the node classpath (it's still possible to run it using the ignite thin client). Most of such handlers and abstractions look like a boilerplate code and must be covered by some internal command exposer.
There are no any sufficient abstractions in any protocol and each protocol has (or has no if you lucky) slightly different logic.
Moreover, format of arguments, help messages and other things are not standardized and have different logic from command to command.
Command Plugin Extension
Ignite plugins have no control over the cluster management operations. The built-in management tasks can't be extended by Ignite running with custom plugins and even more, they can't be available through the standard Ignite's REST, JMX, CLI APIs.
Ignite CLI uses under the hood its own internal communication protocol so-called Binary Rest Protocol which enables CLI tools to communicate with the existing Ignite cluster and run some compute tasks, perform cache operation, as well as has listeners of topology changes. An instance of the GridClient started each time a new management operation executes the same way as an instance of IgniteClient can do which in turn is a part of the official Ignite Binary Protocol. Taking into account that the Binary Rest Protocol which is used for the CLI tool fully undocumented looks like
Ignite has some management tasks that don't obey the role model controlled by SecurityManager and has different execution flow depending on which execution context is set. For instance:
All of the issues above require management tasks to be always being executed in the same manner with the same security context.
The following design issues based on current management task implementation are present:
The following new features can be available out of the box with minimal additional source code changes:
This IEP is primary focused on providing good abstraction for command invocation which includes:
Keeping in mind that command will be described in declarative way all newly created commands will be automatically available and used by all of the features above.
...
String
as a key, and String
or String[]
as a value.BinaryObject
. It may be formatted to different string results depending on what type of client is used (e.g. REST, CLI, JMX). draw.io Diagram | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...