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 <dmekhani...@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 <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 > >>> > >>> >
