You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Denis Mekhanikov <dm...@gmail.com> on 2020/05/13 18:43:19 UTC
Extensions for control.sh
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
Re: Extensions for control.sh
Posted by Anton Vinogradov <av...@apache.org>.
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 <dm...@gmail.com>
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 <dm...@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 <
> dmekhanikov@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
> >>>
> >>>
>
Re: Extensions for control.sh
Posted by Denis Mekhanikov <dm...@gmail.com>.
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 <dm...@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 <dm...@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
>>>
>>>
Re: Extensions for control.sh
Posted by Anton Vinogradov <av...@apache.org>.
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 <dm...@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 <dm...@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
> >
> >
>
Re: Extensions for control.sh
Posted by Denis Magda <dm...@apache.org>.
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 <dm...@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
>
>
Re: Extensions for control.sh
Posted by Alex Plehanov <pl...@gmail.com>.
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 <dm...@gmail.com>:
> 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
>
>