Merged to master.
> 6 июня 2023 г., в 16:19, Nikolay Izhikov написал(а):
>
> Hello, Igniters.
>
> Last couple of weeks we actively worked on Phase 1 of IEP-81.
> Now, after several dozens of feature branch reviews Phase 1 is almost ready.
>
> If you are interested in new Management API, please, join to the reivew.
>
> PR - https://github.com/apache/ignite/pull/10675
> IEP -
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-81+Cluster+Management+API
>
>
>
> On 2021/11/26 13:54:51 Andrey Mashenkov wrote:
>> Hi Maxim,
>>
>> I like the idea, the IEP looks very useful.
>>
>> However, I agree with Nikolay on this
>>
>>>
>>> Don’t think we should rely on auto scan class path capabilities.
>>>1. How this automatic scanner will distinguish ignite class from
>>> user class if they both in node class path and same package like
>>> «org.apache.ignite.internal»?
>>>2. It seems hard to debug any errors with auto class path scanner.
>>> How we ensure correct order of scanning in case different jar order in
>>> class path?
>>
>> I think we should go with some kind of hardcoded «on startup» command
>>> registration.
>>
>>
>> Maybe we could use Java ServiceLoader [1] for this?
>>
>> You can add a list of command classes to e.g.
>> META-INF/services/o.a.i.CommandHandlerProvider,
>> then register all mentioned classes that are found via ServiceLoader.load(
>> CommandHandlerProvider.class)
>> Service loader can return the iterator for all found providers.
>>
>> This will prevent scanning all the classes in classpath and allow to load
>> classes from 3-rd party extensions.
>>
>> [1] https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html
>>
>>
>> On Fri, Nov 26, 2021 at 12:25 PM Nikolay Izhikov
>> wrote:
>>
>>> Hello, Maxim.
>>>
>>> Thanks for the IEP.
>>> I support the intentions and design of the IEP in general but have some
>>> comments:
>>>
AnnotationCommandScanner, PackageCommandScanner, URICommandScanner
>>>
>>> Don’t think we should rely on auto scan class path capabilities.
>>>1. How this automatic scanner will distinguish ignite class from
>>> user class if they both in node class path and same package like
>>> «org.apache.ignite.internal»?
>>>2. It seems hard to debug any errors with auto class path scanner.
>>> How we ensure correct order of scanning in case different jar order in
>>> class path?
>>>
>>> I think we should go with some kind of hardcoded «on startup» command
>>> registration.
>>>
>>>
execute(ProxyManagementTask.class, Map atts)
>>>
>>> 1. Do we have some well-defined place to validate `atts`?
>>>
>>> 2. Do we really need to rely on `java.lang.Class` parameter?
>>>This means executor (thin client) should have all class
>>> definitions which can be hard for plugins provided class.
>>>Can we rely on some kind of «path array» like `String[] {
>>> «baseline», «set» }` or `String[] { «user», «add» }`
>>>So the API usage will looks like:
>>>
>>> ```
>>>String execute(String[] path, Map params)
>>>
>>>Map params = new HashMap();
>>>
>>>params.put(«—login», «admin»)
>>>params.put(«—password», «mypassw0rd»)
>>>
>>>String res = execute(new String[] {«user», «add»}, params);
>>> ```
>>>
>>>
Design issues … it is not possible to add and run new management
>>> tasks at the cluster runtime (e.g. REPL mode for CLI tools can't be used);
>>>
>>> It seems to me as a good thing?
>>> We shouldn’t have ability to add management tasks in runtime from the user
>>> side because of security reasons.
>>>
>>> But, we should be able to run any existing task dynamically in some
>>> scripting environment - REPL, CLI as you mentioned.
>>>
>>>
Features
>>>
>>> I think we should focus on:
>>>
>>> 1. Subsystem then stores all available management tasks
>>> 2. Unified execution flow that guarantees all required things like
>>> authorization, authentication, logging and event generation.
>>> 3. Creation of the specific protocol implementation that will expose all
>>> existing commands **in the same way** through all supported protocols
>>> **without any additional development**.
>>> 4. Simplification of new command development and improvement of existing.
>>>
>>>
Compatibility
>>>
>>> IEP doesn’t clearly define compatibility.
>>> Do we keep all existing commands as is?
>>> Is new subsystem a replacement for current API?
>>>
>>> Is new subsystem will co-exist with current API? For how long?
>>>
26 нояб. 2021 г., в 11:44, Maxim Muzafarov
>>> написал(а):
Igniters,
I'd like to propose a new internal cluster management API that will
simplify new cluster management commands creation and expose new
commands to CLI, REST, JMX Ignite interfaces without any additional
actions from the engineer adding a new command. This main goal of the
IEP is supposed to be available after the implementation of the
