Extensions for control.sh

[Denis Mekhanikov]

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

[Alexey Plekhanov]

Hello Denis,

I support the idea (I've been thinking about it some time ago too).
For plugins, we can introduce a component to extend control.sh and create a
custom component of this class by the plugin.


ср, 13 мая 2020 г. в 21:43, Denis Mekhanikov <[hidden email]>:

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

[dmagda]

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 <[hidden email]>
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
>
>

[Anton Vinogradov-2]

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 <[hidden email]> 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 <[hidden email]>
> 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
> >
> >
>

[Denis Mekhanikov]

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 <[hidden email]> 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 <[hidden email]>
>> 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
>>>
>>>

[Anton Vinogradov-2]

Denis,

> Do you mean, that external plugins should be able to configure the
> connection that is used to communicate with a cluster?
Yes

> Could you give an example ...
The same case I mentioned before.
We may need binary rest attributes to be set.
Some code should get them somewhere (eg. from file, system property, JMV
option, from usb-devce or keyboard) and set then via
clientCfg.setUserAttributes(userAttr); inside control.sh code.

On Thu, May 14, 2020 at 1:20 PM Denis Mekhanikov <[hidden email]>
wrote:

> 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 <[hidden email]> 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 <
> [hidden email]>
> >> 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
> >>>
> >>>
>