ID | IEP- |
81 | |
Author | |
Sponsor | |
Created |
|
Status |
|
|
|
// Define the problem to be solved.
// Provide the design of the solution.
...
Table of Contents |
---|
The IEP is intended to simplify, 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.
For instance, single-node operations may look the following:
Distributed management compute tasks may look the following:
Each time a new management task is added or is required to be added the developer should take into account the following things:
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.
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.
Flow of command execution:
The following design principles are proposed:
./control.sh --system-view ...
./control.sh --baseline-add ...
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
// A - argument type.
// R - result type.
// T - task type. Task implements actual command logic.
public interface Command<A extends IgniteDataTransferObject, R, T extends ComputeTask<VisorTaskArgument<A>, R>> {
public String description();
public Class<A> args();
public Class<T> task();
public void printResult(IgniteDataTransferObject arg, Object res, Consumer<String> printer);
boolean experimental();
boolean confirmable();
Collection<UUID> nodes(Collection<UUID> nodes, A arg);
} |
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
@OneOf(value = {"nodeIds", "nodeId", "allNodes"}, optional = true)
public class SystemViewCommandArg extends IgniteDataTransferObject {
@Positional
@Argument(description = "Name of the system view which content should be printed." +
" Both \"SQL\" and \"Java\" styles of system view name are supported" +
" (e.g. SQL_TABLES and sql.tables will be handled similarly)")
private String systemViewName;
@Argument(
description = "ID of the node to get the system view from (deprecated. Use --node-ids instead). If not set, random node will be chosen",
optional = true
)
private UUID nodeId;
@Argument(
description = "Comma-separated list of nodes IDs to get the system view from. If not set, random node will be chosen",
optional = true
)
private UUID[] nodeIds;
@Argument(
description = "Get the system view from all nodes. If not set, random node will be chosen",
optional = true
)
private boolean allNodes;
// The rest of the code.
} |
Phase-3
// Links to discussions on the devlist, if applicable.
[1] https://www.mail-archive.com/dev@ignite.apache.org/msg49612.html
[3] https://
...
Jira | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|