Anton,

Do you mean, that external plugins should be able to configure the connection that is used to communicate with a cluster? Could you give an example, what kind of plugin would benefit from it?

If there are some connection-specific properties that can change the way how control.sh communicates with a cluster, then it makes sense to donate such configuration to Ignite. Or am I missing something?

Denis

On 14.05.2020 11:43, Anton Vinogradov wrote:
Denis,

In addition to extending the features list it's also important to find some
way to allow customization of control.sh connection configuration/code.
For example, it may be useful to set some attributes to binary rest client.

On Thu, May 14, 2020 at 2:09 AM Denis Magda <dma...@apache.org> wrote:

Perfect idea to use this the tool for configuration and addition of
extensions!

-
Denis


On Wed, May 13, 2020 at 11:43 AM Denis Mekhanikov <dmekhani...@gmail.com>
wrote:

Hi everyone!

Control.sh is a command-line management tool that you can use to manage
your grid and check its vital parameters like topology version or
availability of baseline nodes. It has is good set of commands which are
suitable to work with vanilla Ignite.

There is also a way to extend functionality of Ignite by implementing a
3rd-party plugin or a module. Any plugin or external module should have
some kind of API to manage and monitor its activity.
If a command-line management command needs to be added, then the only
way to achieve that is to provide an additional script, separate from
control.sh. If you use multiple such plugins, then the set of required
tools may grow and lead to confusion, which script should be used to
configure which extension. Instead of doing that it would be convenient
for users to have ability to use the same script, but with an extended
set of options. It should make lifes of 3rd-party vendors easier.

Currently many integrations and community-supported modules are being
moved outside of the core product:

https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization
I think it makes sense to provide a possibility to configure extensions
using control.sh, since their number will grow over time, and some of
them will require some runtime configuration.

What do you think?

Denis


Reply via email to