Add to the Contributors group in JIRA

[Aleksandr Pakhomov]

Hello to the apache dev community, 

I am Pakhomov Aleksandr from Russia and I would like to contribute to the 
project. Could you please add me to the Contributors group in JIRA? 

Thank you.

Re: Add to the Contributors group in JIRA

[Aleksandr Pakhomov]

Hi Ivan, 

My account name is aleksandr.pakhomov

Best regards, 
Aleksandr Pakhomov

> On 5 Apr 2022, at 10:53, Ivan Pavlukhin  wrote:
> 
> Hi Aleksandr,
> 
> Welcome to the Apache Ignite Community!
> 
> What is your account name in Apache JIRA [1]?
> 
> [1] https://issues.apache.org/jira
> 
> Best regards,
> Ivan Pavlukhin
> 
> вт, 5 апр. 2022 г. в 13:40, Aleksandr Pakhomov :
>> 
>> Hello to the apache dev community,
>> 
>> I am Pakhomov Aleksandr from Russia and I would like to contribute to the 
>> project. Could you please add me to the Contributors group in JIRA?
>> 
>> Thank you.

Ignite 3 IEP

[Aleksandr Pakhomov]

Hello, Igniters. I am working on Ignite 3 REST server and a new CLI tool. I’d 
like to develop IEPs both for REST and CLI. Could you please allow me to add 
new pages to the Confluence page 
https://cwiki.apache.org/confluence/display/IGNITE/Proposals+for+Ignite+3.0 ?  
My email is apk...@gmail.com.

Best regards, 
Aleksandr Pakhomov

Re: Ignite 3 IEP

[Aleksandr Pakhomov]

Sure, 

apkhmv

> On 6 May 2022, at 13:05, Andrey Gura  wrote:
> 
> Aleksandr,
> 
> could you please create an Apache Confluence account [1] and provide
> your user name?
> 
> 1. https://cwiki.apache.org/confluence/signup.action
> 
> On Thu, May 5, 2022 at 7:24 PM Aleksandr Pakhomov  wrote:
>> 
>> Hello, Igniters. I am working on Ignite 3 REST server and a new CLI tool. 
>> I’d like to develop IEPs both for REST and CLI. Could you please allow me to 
>> add new pages to the Confluence page 
>> https://cwiki.apache.org/confluence/display/IGNITE/Proposals+for+Ignite+3.0 
>> ?  My email is apk...@gmail.com.
>> 
>> Best regards,
>> Aleksandr Pakhomov

Re: Ignite 3 IEP

[Aleksandr Pakhomov]

Thank you, I can create pages.

> On 6 May 2022, at 14:17, Andrey Gura  wrote:
> 
> Permissions are granted. Please, check.
> 
> On Fri, May 6, 2022 at 1:32 PM Aleksandr Pakhomov  wrote:
>> 
>> Sure,
>> 
>> apkhmv
>> 
>>> On 6 May 2022, at 13:05, Andrey Gura  wrote:
>>> 
>>> Aleksandr,
>>> 
>>> could you please create an Apache Confluence account [1] and provide
>>> your user name?
>>> 
>>> 1. https://cwiki.apache.org/confluence/signup.action
>>> 
>>> On Thu, May 5, 2022 at 7:24 PM Aleksandr Pakhomov  wrote:
>>>> 
>>>> Hello, Igniters. I am working on Ignite 3 REST server and a new CLI tool. 
>>>> I’d like to develop IEPs both for REST and CLI. Could you please allow me 
>>>> to add new pages to the Confluence page 
>>>> https://cwiki.apache.org/confluence/display/IGNITE/Proposals+for+Ignite+3.0
>>>>  ?  My email is apk...@gmail.com.
>>>> 
>>>> Best regards,
>>>> Aleksandr Pakhomov
>> 

[DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Aleksandr Pakhomov]

Hello, Igniters. 

I'd like to add a few 3rd party libraries to Ignite 3 Java Code Style Guide 
[1]. As I mentioned in IEP-87 [2], it will be: 
Micrionaut for REST [3]
Swagger for Open API annotations [4]
Micronaut serde for REST serialization [5]

WDYT? Any objections? Also, comments on IEP-87 are welcomed.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
[2] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
[3] https://micronaut.io/docs/
[4] https://swagger.io
[5] https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide/

--
Best regards, 
Aleksandr Pakhomov

[DISCUSSION] IEP-87: Open API support for REST

[Aleksandr Pakhomov]

Hello, Igniters. 

I’d like to start a discussion about Open API support for REST [1]. The main 
purpose of this improvement is to add the support of Open API specification by 
generating it from the source code. 

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST

Re: [DISCUSSION] IEP-87: Open API support for REST

[Aleksandr Pakhomov]

Hi, Andrey. 

Thank you for your comments.

I've put the main value to the description and added "artifact management" part 
[1].
Yes, you are right. I've adjusted the IEP.
   3, 4, 5. Done.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Artifactmanagement
 
<https://cwiki.apache.org/confluence/display/IGNITE/IEP-87:+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Artifactmanagement>


> On 11 May 2022, at 16:46, Andrey Gura  wrote:
> 
> Hi,
> 
> I took a look at the proposal and have some questions and comments.
> 
> 1. It is not clear what the main value of this proposal is. The
> current implementation of REST is code-first. API specification could
> be written manually. It seems that the main value is the possibility
> to generate an API specification from code. If so, then it would be
> great to point it out strongly. Otherwise, this proposal looks like an
> attempt to replace one implementation by another one (may be more
> popular) but with additional 3rd party dependencies. Also, it would be
> great to propose a process of artefact management (what should we do
> and when) in relation to specification (Where it should be published?
> Should it be placed in a source code repository or not? Should we do
> some version management?)
> 
> 2. The "Modular architecture support" part says: "Ignite modules can
> provide endpoints that will be included into the netty server by
> RestComponent **at the build time**". If I understood correctly, we
> talk only about endpoints here, but registration/deregistration of
> handlers for known endpoints could be done at runtime. Am I right?
> 
> 3. The "API" part refers to the meta storage nodes and CMG nodes.
> Could you please refer to a document which introduces these concepts?
> 
> 4. Also it would be great to state that the proposed API actually is
> the current API which exists in Apache Ignite.
> 
> 5. The task about developer documentation should be added to the
> issues list. The documentation is a readme.md file which will help an
> Ignite developer to understand how to add a new endpoint, how to
> generate API specification, etc.
> 
> On Wed, May 11, 2022 at 11:17 AM Aleksandr Pakhomov  wrote:
>> 
>> Hello, Igniters.
>> 
>> I’d like to start a discussion about Open API support for REST [1]. The main 
>> purpose of this improvement is to add the support of Open API specification 
>> by generating it from the source code.
>> 
>> [1] 
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST

[DISCUSSION] IEP-88: CLI Tool

[Aleksandr Pakhomov]

Hello, Igniters. 

I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The main 
value is to develop a user-friendly command-line tool with advanced completions 
and SQL REPL mode.

The set of commands and parameters can be discussed. Questions and comments are 
welcomed.

[1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool 
 

Re: [DISCUSSION] IEP-88: CLI Tool

[Aleksandr Pakhomov]

Hi Maxim. 

Thank you for your comments.

- Yes, the non-interactive mode is supported for all commands except "connect", 
"disconnect", "status".

- Benefits of using REST as a communication realization between CLI and Ignite 
3 cluster:
  1) This approach seems to be the de-facto standard for the client-server 
communication 
  2) CLI can connect to any cluster it has a network connection 
  3) REST component already implemented in Ignite 3
  4) REST client can be generated from Open API specification (see IEP-87 
<https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST>).
  5) REST is languege-agnostic, so web ui or third party software can consume 
an API spec provided by the server.

- Drawbacks of using REST: additional client and server libraries have to be 
included to the CLI and Ignite distributions.

As for alternatives, I would mention that the custom sdk could be an option. 
But it requires a lot of afford to design and develop and can be used only by 
Java clients. 

- Yes, the command autocomplition provided out of the box. I've added an 
information about this.

I'll add a brief overview of popular CLIs to the IEP.


> On 13 May 2022, at 15:05, Maxim Muzafarov  wrote:
> 
> Hello Aleksanrd,
> 
> 
> The description looks good. A few questions below:
> 
> - Can the CLI also be run in non-interactive mode to support scripts
> execution (like the WildFly it does [1])? Will it be possible though
> the REST it used?
> - What is the benefits and drawbacks of using REST for this tool? Are
> there any alternative for that?
> - Would we have command autocomplition out of the box? It doesn't
> mentioned, but seems to be a very user friendly ability.
> 
> Can you provide a briefly comparison for such a CLI tools for other
> databases and/or systems, application servers? It seems the developing
> CLI tool is a common task, so I think at least we should mention about
> the common development approach in modern systems for such tools. For
> instance, I'm very excited with the wildfly-cli tool usage, however,
> may be it has some drawbacks too.
> 
> [1] https://kb.novaordis.com/index.php/WildFly_CLI_Scripting
> 
> On Thu, 12 May 2022 at 23:43, Aleksandr Pakhomov  wrote:
>> 
>> Hello, Igniters.
>> 
>> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The 
>> main value is to develop a user-friendly command-line tool with advanced 
>> completions and SQL REPL mode.
>> 
>> The set of commands and parameters can be discussed. Questions and comments 
>> are welcomed.
>> 
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool 
>> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-88:+CLI+Tool>

Re: [DISCUSSION] IEP-88: CLI Tool

[Aleksandr Pakhomov]

Hi Misha.

Thank you for your valid points.

I accept your suggestion about "ignite cli config get/set" naming.
As for default commands, I think "clear" and "exit" are only for REPL mode and 
I'll add them to the description of the commands. "ignite help" is already 
defined there.

> On 13 May 2022, at 17:04, Mikhail Pochatkin  wrote:
> 
> Hello, Sasha.
> 
> The description looks good to me, only a few comments.
> 
> 1. I would suggest renaming the CLI configuration command. Currently
> "ignite default get" and "ignite default set" look not informative. I
> understand that "ignite config" is already used for the Ignite
> configuration command and this is a problem to find another good name for
> this command. My suggestion is "ignite cli config", if anyone has a better
> variant, you are welcome.
> 2. I think that Ignite CLI should also have default commands like "ignite
> help", "ignite clear", "ignite exit" and etc. Could you please add topics
> about these commands.
> 
> On Thu, May 12, 2022 at 11:43 PM Aleksandr Pakhomov 
> wrote:
> 
>> Hello, Igniters.
>> 
>> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The
>> main value is to develop a user-friendly command-line tool with advanced
>> completions and SQL REPL mode.
>> 
>> The set of commands and parameters can be discussed. Questions and
>> comments are welcomed.
>> 
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool
>> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-88:+CLI+Tool>

[DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Aleksandr Pakhomov]

Hello, Igniters.

I would like to start a discussion about Java Code Style Guide [1] changes that 
are going to be a part of IEP-87 [2] implementation. The set of libraries and 
frameworks that are going to be allowed to be used in production:
- Micronaut for REST Server [3] 
- Swagger for Open API annotations [4] 
- Micronaut serde for REST serialization [5] 

Any objections? Also, comments on IEP-87 are welcomed. 
[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
 

 
[2] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
 

 
[3] https://micronaut.io/docs / 
[4] https://swagger.io  
[5] https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide 
/

Re: [DISCUSSION] IEP-88: CLI Tool

[Aleksandr Pakhomov]

Hi, Andrey

Thanks for comments.

1. Does “Ignite shell” sounds better? 

2. Yes, you are right. Most tools print help if they are executed without   
arguments. But I did not get your point about scripting. What do you mean by 
saying “it will just hang”?  What kind of error is going to be the cause of 
such behaviour?

> On 18 May 2022, at 21:14, Andrey Gura  wrote:
> 
> Hi,
> 
> My two cents:
> 
> 1. CLI Tool - looks like not the best name :) Shell?
> 
> 2. The description says: "REPL mode is used by default and is
> activated if the ignite command is executed without parameters."
> 
> I think it is a bad idea. Firstly, it is usual CLI's behaviour to
> print a help for a user. An exception if we would use a special CLI
> for REPL. Shell? :)
> Also such approach breaks my expectations related to a scripting. In
> case of an error in a script it will just hang. So, a separate CLI
> utility looks better than ignite CLI.
> 
> 
> On Thu, May 12, 2022 at 11:43 PM Aleksandr Pakhomov  wrote:
>> 
>> Hello, Igniters.
>> 
>> I’d like to start a discussion about Ignite 3 Command Line Tool [1]. The 
>> main value is to develop a user-friendly command-line tool with advanced 
>> completions and SQL REPL mode.
>> 
>> The set of commands and parameters can be discussed. Questions and comments 
>> are welcomed.
>> 
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool 
>> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-88:+CLI+Tool>

Re: [DISCUSSION] IEP-88: CLI Tool

[Aleksandr Pakhomov]

I got it. What do you think about this proposal:

-  “ignite”  prints help 
-  “ignite shell” enters REPL

Or

-  “ignite” prints help 
-  “ignite-shell” enters REPL and it is a separate application

I prefer the first varian but I would like to hear opinions of other community 
members.


> On 19 May 2022, at 01:16, Andrey Gura  wrote:
> 
> I can just have a mistake in my script, e.g. running ignite command
> without any parameters. What will happen in such a case from the
> script perspective? I think the script will wait for returning value
> while the shell will wait for a user input. Due to a server-side
> nature of the script it will hang forever because there is no user on
> the server side.

Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Aleksandr Pakhomov]

Hi, Eduard

Thank you for pointing out the 140 symbol column limit.
Il’l follow this.

As for transitive dependencies, good point. I would mention
that not only class loader magic can be implemented but 
Micronaut libraries could be shadowed in order not to 
cause the jar-hell issues for clients.

> On 19 May 2022, at 01:40, Eduard Rakhmankulov  wrote:
> 
> Hi, Igniters!
> 
> I am really glad about the 140 symbol column limit.
> 
> But aside from possible vulnerabilities mentioned above I have other
> concerns, which may affect some future users.
> 
> Micronaut is a rather popular framework. Are we planning some OSGI support
> (or custom classloader magic) so users which have been already using
> micronaut don't need to be bound to the version transitively inherited by
> ignite dependencies?
> 
> On Thu, 19 May 2022 at 00:32, Andrey Gura  wrote:
> 
>> I personally don't support any additional 3rd party dependencies as
>> well as I don't fully understand the value of autogenerated specs for
>> REST endpoints. In my opinion we have another option: writing spec
>> manually. This option doesn't require any of proposed dependencies and
>> allow to avoid possible vulnerabilities. Of course at the cost of
>> manual actions.
>> 
>> I understand that my statement is arguable. So I'll just wait for
>> opinions of other community members.
>> 
>> On Mon, May 16, 2022 at 7:45 PM Aleksandr Pakhomov 
>> wrote:
>>> 
>>> 
>>> Hello, Igniters.
>>> 
>>> I would like to start a discussion about Java Code Style Guide [1]
>> changes that are going to be a part of IEP-87 [2] implementation. The set
>> of libraries and frameworks that are going to be allowed to be used in
>> production:
>>>- Micronaut for REST Server [3]
>>>- Swagger for Open API annotations [4]
>>>- Micronaut serde for REST serialization [5]
>>> 
>>> Any objections? Also, comments on IEP-87 are welcomed.
>>> [1]
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>> <
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>>> 
>>> [2]
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>> <
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>>> 
>>> [3] https://micronaut.io/docs <https://micronaut.io/docs>/
>>> [4] https://swagger.io <https://swagger.io/>
>>> [5]
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
>> <
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
>>> /
>> 

Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Aleksandr Pakhomov]

Hi, Alexander 

Micronaut is chosen as a lightweight framework that 
is is compatible with swagger generators. One who 
develops an endpoint just writes a regular micronaut 
annotations and gets specification generated from it. 

I get your concerns about additional library, but 
micronaut itself is quite small. 

As for serialisation lib, current implementation uses
jackson-databind that has some drawbacks like
possible security issues (CVE) due to its dynamic
nature. Micronaut serde does nothing at runtime 
and is small enough. The IEP replaces (that is 
important) one with another and I’ll add this
information into the description.

> On 19 May 2022, at 13:17, Alexander Polovtcev  wrote:
> 
> Hello, Aleksandr!
> 
> I agree with the usage of Swagger for generating REST API specifications as
> it, for example, removes the burden of manually keeping the documentation
> up to date. However, why do we need the Micronaut framework? No other
> modules use it, and it brings a lot of dependencies that you will have to
> shadow somehow. AFAIK current implementation uses a pure Netty approach and
> is quite small in size. My other concern is using Micronaut serde for
> serialization. We already have other serialization libraries as
> dependencies and do we really need another one?
> 
> On Thu, May 19, 2022 at 1:06 PM Aleksandr Pakhomov  wrote:
> 
>> Hi, Eduard
>> 
>> Thank you for pointing out the 140 symbol column limit.
>> Il’l follow this.
>> 
>> As for transitive dependencies, good point. I would mention
>> that not only class loader magic can be implemented but
>> Micronaut libraries could be shadowed in order not to
>> cause the jar-hell issues for clients.
>> 
>>> On 19 May 2022, at 01:40, Eduard Rakhmankulov 
>> wrote:
>>> 
>>> Hi, Igniters!
>>> 
>>> I am really glad about the 140 symbol column limit.
>>> 
>>> But aside from possible vulnerabilities mentioned above I have other
>>> concerns, which may affect some future users.
>>> 
>>> Micronaut is a rather popular framework. Are we planning some OSGI
>> support
>>> (or custom classloader magic) so users which have been already using
>>> micronaut don't need to be bound to the version transitively inherited by
>>> ignite dependencies?
>>> 
>>> On Thu, 19 May 2022 at 00:32, Andrey Gura  wrote:
>>> 
>>>> I personally don't support any additional 3rd party dependencies as
>>>> well as I don't fully understand the value of autogenerated specs for
>>>> REST endpoints. In my opinion we have another option: writing spec
>>>> manually. This option doesn't require any of proposed dependencies and
>>>> allow to avoid possible vulnerabilities. Of course at the cost of
>>>> manual actions.
>>>> 
>>>> I understand that my statement is arguable. So I'll just wait for
>>>> opinions of other community members.
>>>> 
>>>> On Mon, May 16, 2022 at 7:45 PM Aleksandr Pakhomov 
>>>> wrote:
>>>>> 
>>>>> 
>>>>> Hello, Igniters.
>>>>> 
>>>>> I would like to start a discussion about Java Code Style Guide [1]
>>>> changes that are going to be a part of IEP-87 [2] implementation. The
>> set
>>>> of libraries and frameworks that are going to be allowed to be used in
>>>> production:
>>>>>   - Micronaut for REST Server [3]
>>>>>   - Swagger for Open API annotations [4]
>>>>>   - Micronaut serde for REST serialization [5]
>>>>> 
>>>>> Any objections? Also, comments on IEP-87 are welcomed.
>>>>> [1]
>>>> 
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>>>> <
>>>> 
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>>>>> 
>>>>> [2]
>>>> 
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>>>> <
>>>> 
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>>>>> 
>>>>> [3] https://micronaut.io/docs <https://micronaut.io/docs>/
>>>>> [4] https://swagger.io <https://swagger.io/>
>>>>> [5]
>>>> 
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
>>>> <
>>>> 
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
>>>>> /
>>>> 
>> 
>> 
> 
> -- 
> With regards,
> Aleksandr Polovtcev

Re: [DISCUSSION] IEP-87: Open API support for REST

[Aleksandr Pakhomov]

Hi Roman,

Thanks for the note. I’ve updated ‘Versioning’ paragraph 
with the example.

> On 19 May 2022, at 10:12, Roman Puchkovskiy  
> wrote:
> 
> Hi Aleksandr.
> 
> Thank you for your effort, it looks interesting. I have a few
> comments/questions on some little details.
> 
> 1. About the paragraph named 'Versioning'. Could you please elaborate
> what is the difference between 'API version' and 'specification
> version'? Both might have 'breaking changes', what does it mean in
> each of the cases?

Re: [DISCUSSION] IEP-87: Open API support for REST

[Aleksandr Pakhomov]

Yes, micronaut injection is going to be used but 
only for controllers. The border is MicronautFactory
(see RestComponent constructor in the example).
This factory declares beans that are needed for 
controllers. Each module declares its own factory.
List of factories are put to RestComponent
manually and then they are set to the context 
as singletons.

> On 19 May 2022, at 10:12, Roman Puchkovskiy  
> wrote:
> 
> 2. If I'm not mistaken, at runtime, Micronaut maintains an application
> context containing beans, these beans can be injected into other beans
> and components (like controllers). In your example code, RestComponent
> receives a RestConfiguration instance via constructor. Is the
> RestConfiguration instance injected automatically by the Micronaut IoC
> container? Is the IoC injection going to be used at all? If yes, given
> that currently Ignite 3 uses no such automagic injection, then what
> are the planned/supposed bounds of the area which would use automatic
> injection and how will we build the 'border' between auto-injecting
> and non-auto-injecting code? (For instance, how our RestConfiguration
> will be registered with the Micronaut context?)
> As a sidenote

Re: [DISCUSSION] IEP-87: Open API support for REST

[Aleksandr Pakhomov]

Agreed. Thank you for comments, Roman.

> On 19 May 2022, at 10:17, Roman Puchkovskiy  
> wrote:
> 
> 3. In the table in the API section, there is this phrase: 'Update node
> configuration with a given body.'. I suggest replacing 'Update' with
> 'Patch' because 'update' could mean a full replacement, and 'patch'
> makes it more specific. Same relates to 'Update cluster configuration
> with a given body.'.

Re: [DISCUSSION] IEP-88: CLI Tool

[Aleksandr Pakhomov]

Hi Ilya,

Thanks for the python usage example.

AWS cli does not support interactive mode at all. 
Google too. Even Google Big query cli [1] executes
sql queries without interactive shell. 

For REPL-first tools like Reql [2], ksqlDB CLI [3], or 
SnowSQL [4] it is common thing to enter the REPL 
if command was executed without any arguments. 

CLIs that do not support the REPL (or REPL is not
the main value of those tools) tend to print help on 
empty arguments. 



[1] https://cloud.google.com/bigquery/docs/bq-command-line-tool 
<https://cloud.google.com/bigquery/docs/bq-command-line-tool>
[2] https://github.com/Workshape/reql-cli 
<https://github.com/Workshape/reql-cli> 
[3] 
https://docs.ksqldb.io/en/latest/operate-and-deploy/installation/cli-config/ 
<https://docs.ksqldb.io/en/latest/operate-and-deploy/installation/cli-config/>
[4] https://docs.snowflake.com/en/user-guide/snowsql-use.html 
<https://docs.snowflake.com/en/user-guide/snowsql-use.html> 

> On 19 May 2022, at 11:44, Ilya Korol  wrote:
> 
> From my perspective we should move towards existing UX approaches. For 
> example:
> python - enters shell
> python --help  - prints help
> python -c - executes command
> 
> What about other CLI tools that works with remote services? I can't remember 
> properly but do AWS, openshift or maybe GCP CLIs also supports shell mode? If 
> so, how it is organized?
> 
> 19.05.2022 17:53, Aleksandr Pakhomov пишет:
>> I got it. What do you think about this proposal:
>> 
>> -  “ignite”  prints help
>> -  “ignite shell” enters REPL
>> 
>> Or
>> 
>> -  “ignite” prints help
>> -  “ignite-shell” enters REPL and it is a separate application
>> 
>> I prefer the first varian but I would like to hear opinions of other 
>> community members.
>> 
>> 
>>> On 19 May 2022, at 01:16, Andrey Gura  wrote:
>>> 
>>> I can just have a mistake in my script, e.g. running ignite command
>>> without any parameters. What will happen in such a case from the
>>> script perspective? I think the script will wait for returning value
>>> while the shell will wait for a user input. Due to a server-side
>>> nature of the script it will hang forever because there is no user on
>>> the server side.
>> 

Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Aleksandr Pakhomov]

Hi Andrey,

Thank you for the valuable arguments.

Speaking about micronaut, it is a popular library that 
provides a lot of build-in features like error handling, 
auth, IoC, test infrastructure, and many more. The main 
functionality of micronaut framework is REST, so this 
library is scanned for vulnerabilities regularly and fixes 
them asap (looking to [1] it takes about a week). 
I don't  think that Ignite REST server implementation 
will be scanned as regular as micronaut and issues 
will be fixed as quickly as micronaut does.

As for autogenerated spec, I would mention that manual
spec writing introduces the second source of truth for 
the API. So, implementation declares one API, spec 
declares another API and there is no prooved contract
between them. For example, a developer adds "name" 
parameter to the existing endpoint and goes to the 
spec and adds "names" parameter there (makes a mistake). 
What is the right parameter here "name" or "names"? 
Also, if there won't be a compatibility test this mistake could 
go to the production and API spec consumers could get 
a REST client that is not compatible with the server.


> On 19 May 2022, at 00:32, Andrey Gura  wrote:
> 
> I personally don't support any additional 3rd party dependencies as
> well as I don't fully understand the value of autogenerated specs for
> REST endpoints. In my opinion we have another option: writing spec
> manually. This option doesn't require any of proposed dependencies and
> allow to avoid possible vulnerabilities. Of course at the cost of
> manual actions.
> 
> I understand that my statement is arguable. So I'll just wait for
> opinions of other community members.

Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Aleksandr Pakhomov]

Yes, swagger-core has its own set of annotations [1] 

[1] 
https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#quick-annotation-overview

> On 23 May 2022, at 12:37, Alexander Polovtcev  wrote:
> 
> I'm not that scared of having a big library, I just believe that it might
> be possible to avoid using it altogether. Don't swagger generators have
> their own annotations?

Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Aleksandr Pakhomov]

Yes, you are right about the usage of Jackson
in another modules. So, the “replacement” is 
not an argument any more.

> On 23 May 2022, at 12:37, Alexander Polovtcev  wrote:
> 
> My concern is that we will still use Jackson in other modules, like
> sql-engine, for example. Or will you replace this library completely in all
> modules?

[VOTE] Add swagger dependency to Ignite 3

[Aleksandr Pakhomov]

Dear community,

Discussion about 3rd party dependencies took place 
and I think it is time to vote if we agreed to include 
swagger dependency to the Ignite 3 or not. 

The exact list of dependencies could be fined in IEP-87 [1] 
(swagger-annotations, swagger-core, 
swagger-codegen-maven-plugin)

Micronaut is out of the scope of this voting. I will launch 
a separate one.

The vote is formal, see voting guidelines [2]

+1 - to accept additional dependencies to be included to Java code Guidelines 
[3]
0 - don't care either way 
-1 - DO NOT accept (explain why)

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
[2] https://www.apache.org/foundation/voting.html 
 
[3] 
https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries

[VOTE] Add micronaut dependency to Ignite 3

[Aleksandr Pakhomov]

Dear community,

Micronaut-based REST server implementation was a hot 
topic we discussed in the previous week. So, I've separeted
votes about swagger and micronaut. This vote is about 
adding micronaut to the Ignite 3.

The exact list of dependencies could be fined in IEP-87 [1]
io.micronaut.serde:micronaut-serde
io.micronaut:micronaut-context
io.micronaut:micronaut-http
io.micronaut:micronaut-inject
io.micronaut:micronaut-http-server
io.micronaut:micronaut-runtime
io.micronaut:micronaut-core
io.micronaut:micronaut-http-server-netty
io.micronaut:micronaut-http-netty
io.micronaut:micronaut-buffer-netty
io.micronaut:micronaut-aop
io.micronaut:micronaut-core-reactive
Io.micronaut:micronaut-json-core
io.micronaut:micronaut-jackson-core

Swagger is out of the scope of this voting.

The vote is formal, see voting guidelines [2]

+1 - to accept additional dependencies to be included to Java code Guidelines 
[3]
0 - don't care either way 
-1 - DO NOT accept (explain why)

This vote will be open for at least 4 days till Fri May 27, 2022, 
21:00 Moscow TZ.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
[2] https://www.apache.org/foundation/voting.html 
 
[3] 
https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
 

[4] 
https://www.timeanddate.com/countdown/generic?iso=20220527T21&p0=166&msg=%5BVOTE%5D+Add+micronaut+dependency+to+Ignite+3&font=cursive

[VOTE] Add swagger dependency to Ignite 3

[Aleksandr Pakhomov]

This vote will be open for at least 4 days till Fri May 27, 2022, 
21:00 Moscow TZ.

https://www.timeanddate.com/countdown/generic?iso=20220527T21&p0=166&msg=%5BVOTE%5D+Add+swagger+dependency+to+Ignite+3&font=cursive
 
<https://www.timeanddate.com/countdown/generic?iso=20220527T21&p0=166&msg=[VOTE]+Add+swagger+dependency+to+Ignite+3&font=cursive>
 


> On 23 May 2022, at 19:56, Aleksandr Pakhomov  wrote:
> 
> Dear community,
> 
> Discussion about 3rd party dependencies took place 
> and I think it is time to vote if we agreed to include 
> swagger dependency to the Ignite 3 or not. 
> 
> The exact list of dependencies could be fined in IEP-87 [1] 
> (swagger-annotations, swagger-core, 
> swagger-codegen-maven-plugin)
> 
> Micronaut is out of the scope of this voting. I will launch 
> a separate one.
> 
> The vote is formal, see voting guidelines [2]
> 
> +1 - to accept additional dependencies to be included to Java code Guidelines 
> [3]
> 0 - don't care either way 
> -1 - DO NOT accept (explain why)
> 
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>  
> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies>
> [2] https://www.apache.org/foundation/voting.html 
> <https://www.apache.org/foundation/voting.html> 
> [3] 
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>  
> <https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries>

[DISCUSSION] Ignite 3 CLI name

[Aleksandr Pakhomov]

Hi Igniters,

I would like to discuss a name for Ignite 3 CLI [1]. 
Here are candidates from top to bottom.

"Ignite CLI". The most general and straightforward.

"Ignite Shell". It sounds good, only one point: "shell"
is about interpretation, and interaction, but this Ignite CLI 
is not only about interpretation.

"Ignite REPL". Same doubts as for shell.

My personal offer is to use some abstract name that 
does not bring the context about the way how 
commands are executed. It could be "Ignition" and
the terminal application will be called with two
letters ("ignition" too long): "ig", for example: "ig config show".

What do you think? Any ideas are welcome. 

[1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool

Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Aleksandr Pakhomov]

Hi Alexander, 

Yes, swagger allows to annotate classes
and then the spec will be generated. But 
here is a question. What classes should we 
annotade? 

Web framework brings the convention about 
how to write an endpoint and what to annotate. 
Our own REST server implementation does not. 
It is just the number of handlers. 

> On 25 May 2022, at 17:46, Alexander Polovtcev  wrote:
> 
> Aleksandr,
> 
> Can we use these annotations without the micronaut dependencies? If yes,
> why do we need micronaut at all?
> 
> On Mon, May 23, 2022 at 5:34 PM Aleksandr Pakhomov  wrote:
> 
>> Yes, swagger-core has its own set of annotations [1]
>> 
>> [1]
>> https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#quick-annotation-overview
>> 
>>> On 23 May 2022, at 12:37, Alexander Polovtcev 
>> wrote:
>>> 
>>> I'm not that scared of having a big library, I just believe that it might
>>> be possible to avoid using it altogether. Don't swagger generators have
>>> their own annotations?
>> 
>> 
> 

Re: [VOTE] Add swagger dependency to Ignite 3

[Aleksandr Pakhomov]

Hi Ivan, 

Dependencies that are needed for annotating 
classes are going to be included. From those 
annotations Open API spec is generated by 
maven plugin. That’s it. 

If you are asking about swagger ui or any 
web stuff then the answer is no. We are 
not going to include this into production.

> On 26 May 2022, at 07:34, Ivan Pavlukhin  wrote:
> 
> Hi,
> 
> Are we going to include swagger into production packages? I always
> thought (I might be mistaken) that swagger should be used during
> development. Worries are usual:
> 1. Potential vulnerabilities.
> 2. Unintentional use of transitive dependencies.
> 
> Best regards,
> Ivan Pavlukhin
> 
> чт, 26 мая 2022 г. в 00:46, Mikhail Pochatkin :
>> 
>> +1 from me, de facto swagger standard within OpenApi.
>> 
>> On Mon, May 23, 2022 at 7:57 PM Aleksandr Pakhomov  wrote:
>> 
>>> Dear community,
>>> 
>>> Discussion about 3rd party dependencies took place
>>> and I think it is time to vote if we agreed to include
>>> swagger dependency to the Ignite 3 or not.
>>> 
>>> The exact list of dependencies could be fined in IEP-87 [1]
>>> (swagger-annotations, swagger-core,
>>> swagger-codegen-maven-plugin)
>>> 
>>> Micronaut is out of the scope of this voting. I will launch
>>> a separate one.
>>> 
>>> The vote is formal, see voting guidelines [2]
>>> 
>>> +1 - to accept additional dependencies to be included to Java code
>>> Guidelines [3]
>>> 0 - don't care either way
>>> -1 - DO NOT accept (explain why)
>>> 
>>> [1]
>>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>>> [2] https://www.apache.org/foundation/voting.html <
>>> https://www.apache.org/foundation/voting.html>
>>> [3]
>>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries

Re: [DISCUSSION] IEP-88: CLI Tool

[Aleksandr Pakhomov]

Hi Roman, 

That is a good point. In the proposal I mean 
the analogue for existing ‘cluster init’. Maybe 
“distributed configuration” confuses you and
probably I have to name it like “meta-storage”
configuration or something like this.

As for 'ignite init’  I think it would be more clearer
if we rename it to ‘ignite install’ and there won’t 
any confusion at all. 

What do you think?

> On 27 May 2022, at 10:20, Roman Puchkovskiy  
> wrote:
> 
> Hi Aleksandr.
> 
> There is a command named 'init' in your proposal. According to its
> description, it initializes the cluster with a distributed
> configuration. I'm not sure how it's mapped to the existing commands.
> The thing is that currently, there is `ignite init` command that
> initializes (actually, installs) Ignite on the current machine (its
> description does not mention distributed configuration), and there is
> also `ignite cluster init` that initializes the cluster (see [1], for
> example), which does not concern distributed configuration as well.
> 
> So it looks like the 2 existing commands got dropped and replaced with
> another 'init' command relating to the distributed config.
> 
> Was it intentional?
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-14871
> 
> ср, 25 мая 2022 г. в 18:12, Andrey Gura :
>> 
>> Aleksandr,
>> 
>> Both proposed options look good to me because both cases assume that a
>> user must express their intent explicitly.
>> 
>> On Thu, May 19, 2022 at 10:53 AM Aleksandr Pakhomov  wrote:
>>> 
>>> I got it. What do you think about this proposal:
>>> 
>>> -  “ignite”  prints help
>>> -  “ignite shell” enters REPL
>>> 
>>> Or
>>> 
>>> -  “ignite” prints help
>>> -  “ignite-shell” enters REPL and it is a separate application
>>> 
>>> I prefer the first varian but I would like to hear opinions of other 
>>> community members.
>>> 
>>> 
>>>> On 19 May 2022, at 01:16, Andrey Gura  wrote:
>>>> 
>>>> I can just have a mistake in my script, e.g. running ignite command
>>>> without any parameters. What will happen in such a case from the
>>>> script perspective? I think the script will wait for returning value
>>>> while the shell will wait for a user input. Due to a server-side
>>>> nature of the script it will hang forever because there is no user on
>>>> the server side.
>>> 

Re: [DISCUSSION] IEP-88: CLI Tool

[Aleksandr Pakhomov]

Roman, 

Thank you, that makes sense. 

> On 27 May 2022, at 14:26, Roman Puchkovskiy  
> wrote:
> 
> Aleksandr,
> 
> The thing is that `cluster init` is not just for setting some kind of
> a configuration, it's more about doing cluster initialization
> described in [1]. This init process transitions the cluster from
> 'empty' state to 'initialized state'; this can be only made once per
> cluster, and it has to be done for the cluster to function.
> 
> So I'd suggest to remove the mentioning of 'configuration' at all;
> also, `--cluster-url` and `--configuration-file` are not the
> parameters that are currently implemented; it's actually (currently)
> taking `--node-endpoint`, `--meta-storage-node` (1+ occurrences) and
> `--cmg-node` (0+ occurrences) parameters.
> 
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization
> 
> пт, 27 мая 2022 г. в 13:04, Aleksandr Pakhomov :
>> 
>> Hi Roman,
>> 
>> That is a good point. In the proposal I mean
>> the analogue for existing ‘cluster init’. Maybe
>> “distributed configuration” confuses you and
>> probably I have to name it like “meta-storage”
>> configuration or something like this.
>> 
>> As for 'ignite init’  I think it would be more clearer
>> if we rename it to ‘ignite install’ and there won’t
>> any confusion at all.
>> 
>> What do you think?
>> 
>>> On 27 May 2022, at 10:20, Roman Puchkovskiy  
>>> wrote:
>>> 
>>> Hi Aleksandr.
>>> 
>>> There is a command named 'init' in your proposal. According to its
>>> description, it initializes the cluster with a distributed
>>> configuration. I'm not sure how it's mapped to the existing commands.
>>> The thing is that currently, there is `ignite init` command that
>>> initializes (actually, installs) Ignite on the current machine (its
>>> description does not mention distributed configuration), and there is
>>> also `ignite cluster init` that initializes the cluster (see [1], for
>>> example), which does not concern distributed configuration as well.
>>> 
>>> So it looks like the 2 existing commands got dropped and replaced with
>>> another 'init' command relating to the distributed config.
>>> 
>>> Was it intentional?
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-14871
>>> 
>>> ср, 25 мая 2022 г. в 18:12, Andrey Gura :
>>>> 
>>>> Aleksandr,
>>>> 
>>>> Both proposed options look good to me because both cases assume that a
>>>> user must express their intent explicitly.
>>>> 
>>>> On Thu, May 19, 2022 at 10:53 AM Aleksandr Pakhomov  
>>>> wrote:
>>>>> 
>>>>> I got it. What do you think about this proposal:
>>>>> 
>>>>> -  “ignite”  prints help
>>>>> -  “ignite shell” enters REPL
>>>>> 
>>>>> Or
>>>>> 
>>>>> -  “ignite” prints help
>>>>> -  “ignite-shell” enters REPL and it is a separate application
>>>>> 
>>>>> I prefer the first varian but I would like to hear opinions of other 
>>>>> community members.
>>>>> 
>>>>> 
>>>>>> On 19 May 2022, at 01:16, Andrey Gura  wrote:
>>>>>> 
>>>>>> I can just have a mistake in my script, e.g. running ignite command
>>>>>> without any parameters. What will happen in such a case from the
>>>>>> script perspective? I think the script will wait for returning value
>>>>>> while the shell will wait for a user input. Due to a server-side
>>>>>> nature of the script it will hang forever because there is no user on
>>>>>> the server side.
>>>>> 
>> 

Re: [VOTE] Add micronaut dependency to Ignite 3

[Aleksandr Pakhomov]

Andrey, 

Thank you, I will start a new vote soon.

> On 27 May 2022, at 17:29, Andrey Gura  wrote:
> 
> Aleksandr,
> 
> please, start a new vote after updating the IEP-87. I think that
> Micronaut Security is a good reason for using this framework in the
> Apache Ignite.
> 
> 
> 
> On Wed, May 25, 2022 at 5:41 PM Andrey Gura  wrote:
>> 
>> -1 (binding) from me.
>> 
>> Because (if I understood correctly) the main value of the IEP-87 is
>> the possibility to generate API specification and Swagger annotations
>> is enough for this purpose I don't see reasons for these dependencies.
>> We already have our own controllers for REST-like API's
>> implementation. Why can't we just use Swagger annotations only in
>> addition to our rest-api module?
>> 
>> On Mon, May 23, 2022 at 8:08 PM Aleksandr Pakhomov  wrote:
>>> 
>>> Dear community,
>>> 
>>> Micronaut-based REST server implementation was a hot
>>> topic we discussed in the previous week. So, I've separeted
>>> votes about swagger and micronaut. This vote is about
>>> adding micronaut to the Ignite 3.
>>> 
>>> The exact list of dependencies could be fined in IEP-87 [1]
>>> io.micronaut.serde:micronaut-serde
>>> io.micronaut:micronaut-context
>>> io.micronaut:micronaut-http
>>> io.micronaut:micronaut-inject
>>> io.micronaut:micronaut-http-server
>>> io.micronaut:micronaut-runtime
>>> io.micronaut:micronaut-core
>>> io.micronaut:micronaut-http-server-netty
>>> io.micronaut:micronaut-http-netty
>>> io.micronaut:micronaut-buffer-netty
>>> io.micronaut:micronaut-aop
>>> io.micronaut:micronaut-core-reactive
>>> Io.micronaut:micronaut-json-core
>>> io.micronaut:micronaut-jackson-core
>>> 
>>> Swagger is out of the scope of this voting.
>>> 
>>> The vote is formal, see voting guidelines [2]
>>> 
>>> +1 - to accept additional dependencies to be included to Java code 
>>> Guidelines [3]
>>> 0 - don't care either way
>>> -1 - DO NOT accept (explain why)
>>> 
>>> This vote will be open for at least 4 days till Fri May 27, 2022,
>>> 21:00 Moscow TZ.
>>> 
>>> [1] 
>>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
>>> [2] https://www.apache.org/foundation/voting.html 
>>> <https://www.apache.org/foundation/voting.html>
>>> [3] 
>>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>>>  
>>> <https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries>
>>> [4] 
>>> https://www.timeanddate.com/countdown/generic?iso=20220527T21&p0=166&msg=%5BVOTE%5D+Add+micronaut+dependency+to+Ignite+3&font=cursive

[CANCEL] [VOTE] Add micronaut dependency to Ignite 3

[Aleksandr Pakhomov]

This vote is canceled.

The IEP-87 [1] has to be adjusted.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87:+Open+API+support+for+REST

[VOTE] Add micronaut dependency to Ignite 3 (reopened)

[Aleksandr Pakhomov]

Dear community,

We’ve had a productive discussion about 
a micronaut dependency [1]. As a result, 
we’ve came to the conclusion that the 
security support in micronaut is a good 
reason to use this library. I am reopening the 
vote for adding the micronaut dependency to
the rest module. Also, micronaut-serde is 
dropped from the list because Ignite 3 
already uses jackson as a serialisation lib.

List of dependencies:
io.micronaut:micronaut-inject:jar:3.4.1
io.micronaut:micronaut-core:jar:3.4.1
io.micronaut:micronaut-http-server-netty:jar:3.4.1
io.micronaut:micronaut-http-server:jar:3.4.1
io.micronaut:micronaut-router:jar:3.4.1
io.micronaut:micronaut-http-netty:jar:3.4.1
io.micronaut:micronaut-buffer-netty:jar:3.4.1
io.micronaut:micronaut-runtime:jar:3.4.1
io.micronaut:micronaut-http:jar:3.4.1
io.micronaut:micronaut-aop:jar:3.4.1
io.micronaut:micronaut-context:jar:3.4.1
io.micronaut:micronaut-core-reactive:jar:3.4.1

More information about motivation and 
implementation details could be found 
in IEP-87 [2].

The vote is formal, see voting guidelines [3].

+1 - to accept additional dependencies to be included to Java code Guidelines 
[4]
0 - don’t care either way
-1 - DO NOT accept (explain why)

This vote will be open for at leas 3 days till Wed June 1, 2022,
23:00 Moscow TZ [5].


[1] https://lists.apache.org/thread/0nq6wx8t9r036mrjsk6n592gwnvvqbhs 

[2] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST
 

 
[3] https://www.apache.org/foundation/voting.html 

[4] 
https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
 

[5] 
https://www.timeanddate.com/countdown/generic?iso=20220601T23&p0=166&msg=%5BVOTE%5D+Add+micronaut+dependency+to+Ignite+3+%28reopened%29&font=cursive
 

 

[RESULT][VOTE] Add swagger dependency to Ignite 3

[Aleksandr Pakhomov]

Hello Igniters, 

The swagger dependency has been accepted.

3 - “+1” votes received.
1 - “0.5” vote received.

Here are +1 votes received:

- Alexander Polovtcev 
- Andrey Gura
- Ivan Pavlukhin

Here is -0.5 vote received:

- Ilya Kasnacheev (binding)

Link to the voting thread -
https://lists.apache.org/thread/dntnxcyzpddjg5yc5vkd8lxjtd5z54rc 
 

Best regards,
Aleksandr

Re: [RESULT][VOTE] Add swagger dependency to Ignite 3

[Aleksandr Pakhomov]

Andrey,

Thanks, done.

> On 31 May 2022, at 11:36, Andrey Gura  wrote:
> 
> Aleksandr,
> 
> could you please update
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>  
> <https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries>
> 
> On Mon, May 30, 2022 at 12:33 PM Aleksandr Pakhomov  <mailto:apk...@gmail.com>> wrote:
>> 
>> Hello Igniters,
>> 
>> The swagger dependency has been accepted.
>> 
>> 3 - “+1” votes received.
>> 1 - “0.5” vote received.
>> 
>> Here are +1 votes received:
>> 
>> - Alexander Polovtcev
>> - Andrey Gura
>> - Ivan Pavlukhin
>> 
>> Here is -0.5 vote received:
>> 
>> - Ilya Kasnacheev (binding)
>> 
>> Link to the voting thread -
>> https://lists.apache.org/thread/dntnxcyzpddjg5yc5vkd8lxjtd5z54rc 
>> <https://lists.apache.org/thread/dntnxcyzpddjg5yc5vkd8lxjtd5z54rc> 
>> <https://lists.apache.org/thread/dntnxcyzpddjg5yc5vkd8lxjtd5z54rc 
>> <https://lists.apache.org/thread/dntnxcyzpddjg5yc5vkd8lxjtd5z54rc>>
>> 
>> Best regards,
>> Aleksandr

Re: [VOTE] Add micronaut dependency to Ignite 3 (reopened)

[Aleksandr Pakhomov]

Alexander,

I am not sure that now we can define all 
security standards that will be implemented
by Ignite 3. But I can mention the most popular:
OAuth2/OpenId, LDAP. 

I’ve mentioned them in IEP but I believe that
the definite set of security protocols has to
be discussed in another IEP.

> On 30 May 2022, at 12:13, Alexander Polovtcev  wrote:
> 
> Aleksandr,
> Thanks for the update, but can you please explain what security
> capabilities are planned to be used? Maybe it should be included in the IEP
> as well.
> 
> On Sun, May 29, 2022 at 11:03 PM Aleksandr Pakhomov  <mailto:apk...@gmail.com>>
> wrote:
> 
>> Dear community,
>> 
>> We’ve had a productive discussion about
>> a micronaut dependency [1]. As a result,
>> we’ve came to the conclusion that the
>> security support in micronaut is a good
>> reason to use this library. I am reopening the
>> vote for adding the micronaut dependency to
>> the rest module. Also, micronaut-serde is
>> dropped from the list because Ignite 3
>> already uses jackson as a serialisation lib.
>> 
>> List of dependencies:
>> io.micronaut:micronaut-inject:jar:3.4.1
>> io.micronaut:micronaut-core:jar:3.4.1
>> io.micronaut:micronaut-http-server-netty:jar:3.4.1
>> io.micronaut:micronaut-http-server:jar:3.4.1
>> io.micronaut:micronaut-router:jar:3.4.1
>> io.micronaut:micronaut-http-netty:jar:3.4.1
>> io.micronaut:micronaut-buffer-netty:jar:3.4.1
>> io.micronaut:micronaut-runtime:jar:3.4.1
>> io.micronaut:micronaut-http:jar:3.4.1
>> io.micronaut:micronaut-aop:jar:3.4.1
>> io.micronaut:micronaut-context:jar:3.4.1
>> io.micronaut:micronaut-core-reactive:jar:3.4.1
>> 
>> More information about motivation and
>> implementation details could be found
>> in IEP-87 [2].
>> 
>> The vote is formal, see voting guidelines [3].
>> 
>> +1 - to accept additional dependencies to be included to Java code
>> Guidelines [4]
>> 0 - don’t care either way
>> -1 - DO NOT accept (explain why)
>> 
>> This vote will be open for at leas 3 days till Wed June 1, 2022,
>> 23:00 Moscow TZ [5].
>> 
>> 
>> [1] https://lists.apache.org/thread/0nq6wx8t9r036mrjsk6n592gwnvvqbhs <
>> https://lists.apache.org/thread/0nq6wx8t9r036mrjsk6n592gwnvvqbhs 
>> <https://lists.apache.org/thread/0nq6wx8t9r036mrjsk6n592gwnvvqbhs>>
>> [2]
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST
>>  
>> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST>
>> <
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87:+Open+API+support+for+REST
>>  
>> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-87:+Open+API+support+for+REST>>
>> 
>> [3] https://www.apache.org/foundation/voting.html 
>> <https://www.apache.org/foundation/voting.html> <
>> https://www.apache.org/foundation/voting.html 
>> <https://www.apache.org/foundation/voting.html>>
>> [4]
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>>  
>> <https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries>
>> <
>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>>  
>> <https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries>
>>> 
>> [5]
>> https://www.timeanddate.com/countdown/generic?iso=20220601T23&p0=166&msg=%5BVOTE%5D+Add+micronaut+dependency+to+Ignite+3+%28reopened%29&font=cursive
>>  
>> <https://www.timeanddate.com/countdown/generic?iso=20220601T23&p0=166&msg=%5BVOTE%5D+Add+micronaut+dependency+to+Ignite+3+%28reopened%29&font=cursive>
>> <
>> https://www.timeanddate.com/countdown/generic?iso=20220601T23&p0=166&msg=[VOTE]+Add+micronaut+dependency+to+Ignite+3+(reopened)&font=cursive
>>  
>> <https://www.timeanddate.com/countdown/generic?iso=20220601T23&p0=166&msg=[VOTE]+Add+micronaut+dependency+to+Ignite+3+(reopened)&font=cursive>>
>> 
> 
> 
> 
> -- 
> With regards,
> Aleksandr Polovtcev

[RESULT][VOTE] Add micronaut dependency to Ignite 3 (reopened)

[Aleksandr Pakhomov]

Hello Igniters,

The micronaut dependency has been accepted. 
Java Code Style Guild is adjusted [1].

8 - “+1” votes received.

Here are +1 votes received:

- Andrey Gura
- Taras Ledkov
- Tkalenko Kirill
- Alexander Lapin
- Ilya Korol
- Vyacheslav Koptilin
- Alexey
- Semen Danilov

Link to the voting thread [2] 

[1] https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide 

[2] https://lists.apache.org/thread/mrwzck7olzgkt25tzg5co7b6v5so1m93 
 

Best regards, 
Aleksandr

Re: [ANNOUNCE] Apache Ignite 3.0.0 alpha 5: Code freeze

[Aleksandr Pakhomov]

Hi Andrey, 

As for CLI MVP, the planned timeline is today till 21:00. 
Probably, will be ready in an hour. Just waiting for CI build.

Best regards, 
Aleksandr

> On 6 Jun 2022, at 17:56, Andrey Gura  wrote:
> 
> Igniters,
> 
> our release schedule has shifted a bit. But it is time for a code
> freeze and a new branch creation.
> 
> The following issues is still in progress (not an issues status, but
> work state):
> 
> Data rebalancing
> https://issues.apache.org/jira/browse/IGNITE-14209
> 
> CLI MVP
> https://issues.apache.org/jira/browse/IGNITE-16971
> 
> [Native Persistence 3.0] End-to-end test for persistent PageMemory
> https://issues.apache.org/jira/browse/IGNITE-17107
> 
> SQL API: Implement query metadata
> https://issues.apache.org/jira/browse/IGNITE-16962
> 
> SQL API: Add batched DML queries support.
> https://issues.apache.org/jira/browse/IGNITE-16963
> 
> SQL API: Examples.
> https://issues.apache.org/jira/browse/IGNITE-17088
> 
> Please, give some planned timelines for these issues. I would like to
> create the ignite-3.0.0-alpha5 branch today and announce Code Freeze.
> Otherwise, extra steps will be required to include the PR's to the
> release branch.
> 
> Thanks!

Re: [ANNOUNCE] Apache Ignite 3.0.0 alpha 5: Code freeze

[Aleksandr Pakhomov]

Hi Andrey, 

Could you please include this ticket into release? 
https://issues.apache.org/jira/browse/IGNITE-17126 


Thanks

> On 6 Jun 2022, at 17:56, Andrey Gura  wrote:
> 
> Igniters,
> 
> our release schedule has shifted a bit. But it is time for a code
> freeze and a new branch creation.
> 
> The following issues is still in progress (not an issues status, but
> work state):
> 
> Data rebalancing
> https://issues.apache.org/jira/browse/IGNITE-14209
> 
> CLI MVP
> https://issues.apache.org/jira/browse/IGNITE-16971
> 
> [Native Persistence 3.0] End-to-end test for persistent PageMemory
> https://issues.apache.org/jira/browse/IGNITE-17107
> 
> SQL API: Implement query metadata
> https://issues.apache.org/jira/browse/IGNITE-16962
> 
> SQL API: Add batched DML queries support.
> https://issues.apache.org/jira/browse/IGNITE-16963
> 
> SQL API: Examples.
> https://issues.apache.org/jira/browse/IGNITE-17088
> 
> Please, give some planned timelines for these issues. I would like to
> create the ignite-3.0.0-alpha5 branch today and announce Code Freeze.
> Otherwise, extra steps will be required to include the PR's to the
> release branch.
> 
> Thanks!

Re: [ANNOUNCE] New PMC member: Vyacheslav Koptilin

[Aleksandr Pakhomov]

Congratulations! Well-deserved.


> On 17 Aug 2022, at 17:34, Kseniya Romanova  wrote:
> 
> Hi Igniters!
> 
> The Project Management Committee (PMC) for Apache Ignite has invited
> Vyacheslav Koptilin to become a member of the PMC and we are pleased to
> announce that he has accepted.
> 
> Vyacheslav is a veteran committer and contributes a lot to the Ignite
> storage https://github.com/sk0x50.
> 
> Please join me in congratulating Vyacheslav on his new role.
> 
> Best Regards,
> Kseniya Romanova
> on behalf of Apache Ignite PMC

Re: [VOTE] Ignite Packaging IEP

[Aleksandr Pakhomov]

+1

> On 22 Aug 2022, at 17:04, Mikhail Pochatkin  wrote:
> 
> Thank you Anton, for this clarification. Yeah, all points in my previous
> message and IEP only in the context of Ignite 3.
> 
> On Mon, Aug 22, 2022 at 4:18 PM Anton Vinogradov  wrote:
> 
>> It looks like we need to mention that we are talking about Ignite *3* only.
>> Same mention is required at IEP header.
>> 
>> On Mon, Aug 22, 2022 at 4:07 PM Mikhail Pochatkin 
>> wrote:
>> 
>>> Hi Igniters,
>>> 
>>> I want to start a voting process about several points from IEP-93 [1].
>>> 
>>> 1. Switch Apache Ignite build system to Gradle as default.
>>> 2. Consequently, after changing the build system to Gradle we need to add
>>> new third party dependencies to several Gradle plugins. This is list of
>> new
>>> complete time deps:
>>>openapiGenerator = "org.openapi.generator:5.4.0"
>>>javacc = "com.intershop.gradle.javacc:4.0.1"
>>>launch4j = "edu.sc.seis.launch4j:2.5.3"
>>>shadow = "com.github.johnrengelman.shadow:7.1.2"
>>>cmake = "io.github.tomtzook.gradle-cmake:1.0.0"
>>>jreleaser =  "org.jreleaser:1.1.0"
>>> 3. Agreement on all target package formats for Apache Ignite
>> distributions.
>>> 
>>> The vote is formal, see voting guidelines [3].
>>> 
>>> +1 - to accept all points above
>>> 0 - don’t care either way
>>> -1 - DO NOT accept (explain why)
>>> 
>>> This vote will be open for at least 4 days till Friday Aug 26, 2022,
>>> 22:00 Moscow TZ.
>>> 
>>> [1]
>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-93%3A+Ignite+Packaging
>>> [2] https://www.apache.org/foundation/voting.html
>>> 
>> 

Re: Apache Ignite 3.0.0 beta 1 RELEASE [Time, Scope, Manager]

[Aleksandr Pakhomov]

+1

> On 7 Oct 2022, at 23:05, Andrey Gura  wrote:
> 
> Hi, Igniters!
> 
> It's time for a new release of Apache Ignite 3 beta 1. The expected
> feature list consists of:
> 
> - RPM and DEB packages: simplified installation and node management
> with system services.
> - Client's Partition Awareness: Clients are now aware of data
> distribution over the cluster nodes which helps avoid additional
> network transmissions and lowers operations latency.
> - C++ client:  Basic C++ client, able to perform operations on data.
> - Autogenerated values: now a function can be specified as a default
> value generator during a table creation. Currently only
> gen_random_uuid is supported.
> - SQL Transactions.
> - Transactional Protocol: improved locking model, multi-version based
> lock-free read-only transactions.
> - Storage: A number of improvements to memory-only and on-disk engines
> based on Page Memory.
> - Indexes: Basic functionality, hash and sorted indexes.
> - Client logging: A LoggerFactory may be provided during client
> creation to specify a custom logger for logs generated by the client.
> - Metrics framework: Collection and export of cluster metrics.
> 
> I want to propose myself to be the release manager of the Apache
> Ignite 3 beta 1.
> 
> Also I propose the following milestones for the release:
> 
> Scope Freeze: October 12, 2022
> Code Freeze: October 20, 2022
> Voting Date: October 31, 2022
> Release Date: November 5, 2022
> 
> WDYT?

Re: [ANNOUNCE] Welcome Kirill Tkalenko as a new committer

[Aleksandr Pakhomov]

Congratulations!

> On 10 Oct 2022, at 22:15, Pavel Tupitsyn  wrote:
> 
> The Project Management Committee (PMC) for Apache Ignite
> has invited Kirill Tkalenko to become a committer and we are pleased
> to announce that they have accepted.
> 
> Kirill is an active contributor and community member, he made significant
> additions to Ignite 2.x and 3.x code bases, WAL and PageMemory improvements
> among others.
> 
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
> 
> Please join me in welcoming Kirill, and congratulating him on the new role
> in
> the Apache Ignite Community!
> 
> Regards,
> Pavel Tupitsyn

Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE

[Aleksandr Pakhomov]

Hi, Igniters.

I would like to ask you to add a couple of tickets that are required for 
packaging:

https://issues.apache.org/jira/browse/IGNITE-17781 
 
https://issues.apache.org/jira/browse/IGNITE-17773 


These tickets are the last tickets in the packaging scope for beta1.

--
Best regards, 
Aleksandr

> On 19 Oct 2022, at 21:48, Вячеслав Коптилин  wrote:
> 
> Hi Yuriy,
> 
> Let's add them. I hope that these three tasks are the last ones.
> 
> Thanks,
> S.
> 
> ср, 19 окт. 2022 г. в 16:41, Юрий :
> 
>> Slava, thank you.
>> 
>> During cherry picking one of aforementioned ticket was observed dependency
>> on
>> https://issues.apache.org/jira/browse/IGNITE-17907
>> https://issues.apache.org/jira/browse/IGNITE-17671
>> https://issues.apache.org/jira/browse/IGNITE-17816
>> 
>> So, I propose adding them into the release scope.
>> 
>> ср, 19 окт. 2022 г. в 15:53, Вячеслав Коптилин :
>> 
>>> Hi Yuriy,
>>> 
>>> I agree, let's add them to the scope.
>>> 
>>> Thanks,
>>> S.
>>> 
>>> 
>>> ср, 19 окт. 2022 г. в 15:20, Юрий :
>>> 
 Dear Release managers and Igniters,
 
 I would like to add the following tickets to Ignite 3.0.0 beta1:
 
 https://issues.apache.org/jira/browse/IGNITE-17820 - improvement SQL
>> and
 required for the next ticket
 https://issues.apache.org/jira/browse/IGNITE-17748 - related to
>> support
>>> of
 indexes
 https://issues.apache.org/jira/browse/IGNITE-17612 - fix issue when
>> some
 queries couldn't be done.
 https://issues.apache.org/jira/browse/IGNITE-17330 - support RO
 transaction
 by SQL
 https://issues.apache.org/jira/browse/IGNITE-17859 - index filling
 https://issues.apache.org/jira/browse/IGNITE-17813 - related to
>> support
 indexes by SQL
 https://issues.apache.org/jira/browse/IGNITE-17655 - related to
>> support
 indexes by SQL
 
 ср, 19 окт. 2022 г. в 12:11, Вячеслав Коптилин <
>> slava.kopti...@gmail.com
 :
 
> Hello Alexander,
> 
> Thank you for pointing this out. I fully support including RO
 transactions
> into the scope of Ignite 3.0.0-beta1 release.
> 
> Thanks,
> S.
> 
> 
> ср, 19 окт. 2022 г. в 11:42, Alexander Lapin :
> 
>> Igniters,
>> 
>> I would like to add following tickets to ignite-3.0.0-beta1
>> https://issues.apache.org/jira/browse/IGNITE-17806
>> https://issues.apache.org/jira/browse/IGNITE-17759
>> https://issues.apache.org/jira/browse/IGNITE-17637
>> https://issues.apache.org/jira/browse/IGNITE-17263
>> https://issues.apache.org/jira/browse/IGNITE-17260
>> 
>> It's all about read-only transactions.
>> 
>> Best regards,
>> Alexander
>> 
>> пт, 14 окт. 2022 г. в 19:45, Andrey Gura :
>> 
>>> Igniters,
>>> 
>>> The 'ignite-3.0.0-beta1' branch was created (the latest commit is
>>> 8160ef31ecf8d49f227562b6f0ab090c6b4438c1).
>>> 
>>> The scope for the release is frozen.
>>> 
>>> It means the following:
>>> 
>>> - Any issue could be added to the release (fixVersion ==
>>> 3.0.0-beta1)
>>> only after discussion with the community and a release manager in
 this
>>> thread.
>>> - Any commit to the release branch must be also applied to the
>>> 'main'
>>> branch.
>>> 
>> 
> 
 
 
 --
 Живи с улыбкой! :D
 
>>> 
>> 
>> 
>> --
>> Живи с улыбкой! :D
>> 

Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE

[Aleksandr Pakhomov]

Hi Igniters, 

I would like to ask you to add two more tickets to the beta1: 

- https://issues.apache.org/jira/browse/IGNITE-18036 

- https://issues.apache.org/jira/browse/IGNITE-18025 
 

Both of them now have PR's into the main. 

Best regards, 
Aleksandr

> On 15 Oct 2022, at 00:45, Andrey Gura  wrote:
> 
> Igniters,
> 
> The 'ignite-3.0.0-beta1' branch was created (the latest commit is
> 8160ef31ecf8d49f227562b6f0ab090c6b4438c1).
> 
> The scope for the release is frozen.
> 
> It means the following:
> 
> - Any issue could be added to the release (fixVersion == 3.0.0-beta1)
> only after discussion with the community and a release manager in this
> thread.
> - Any commit to the release branch must be also applied to the 'main' branch.

[DISCUSSION] Enable Doclint for Ignite 3

[Aleksandr Pakhomov]

Hi Igniters,

I'm working on the javadoc generation in gradle and I mentioned that now 
standard Doclint [1] is disabled in the maven javadoc generation. I wonder to 
know why it is disabled.

I would suggest enabling Doclint by default because it is a recommended and 
standard approach to dealing with javadoc. Now blind enabling causes lint 
errors but I think I can fix all of them in my PR. 

WDYT?

[1] https://openjdk.org/jeps/172 

--
Best regards, 
Aleksandr

RE: [DISCUSSION] Enable Doclint for Ignite 3

[Aleksandr Pakhomov]

Here is my PR with enabling DocLint 
https://github.com/apache/ignite-3/pull/1320 
<https://github.com/apache/ignite-3/pull/1320> 

I wonder if someone can take a look.

-- 
Best regards,
Aleksandr

On 2022/11/07 11:45:48 Aleksandr Pakhomov wrote:
> Hi Igniters,
> 
> I'm working on the javadoc generation in gradle and I mentioned that now 
> standard Doclint [1] is disabled in the maven javadoc generation. I wonder to 
> know why it is disabled.
> 
> I would suggest enabling Doclint by default because it is a recommended and 
> standard approach to dealing with javadoc. Now blind enabling causes lint 
> errors but I think I can fix all of them in my PR. 
> 
> WDYT?
> 
> [1] https://openjdk.org/jeps/172 <https://openjdk.org/jeps/172>
> 
> --
> Best regards, 
> Aleksandr

Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3

[Aleksandr Pakhomov]

Hi Ivan,

Why do we add reactor dependency? The Ignite 3 codebase
uses java async API. Just wonder to know it we could escape
the usage of third party async libraries.

--
Best regards,
Aleksandr

> On 3 Feb 2023, at 10:51, Ivan Gagarkin  wrote:
> 
> I'd like to add a few 3rd party libraries to Ignite 3
> 
>   1. Micronaut Security
>   https://micronaut-projects.github.io/micronaut-security/latest/guide/
>   2. Micronaut Reactor
>   https://micronaut-projects.github.io/micronaut-reactor/latest/guide/
> 
> We have to have them for authentication and authorization in the REST.
> https://issues.apache.org/jira/browse/IGNITE-18576
> 
> WDYT? Any objections? Also, comments on IEP-87 are welcomed.
> -- 
> Best Regards, Ivan

Re: [ANNOUNCE] Welcome Alexander Pakhomov as a new committer

[Aleksandr Pakhomov]

Thank you! 

I will to my best to contribute to make Apache Ignite even better product.

-- 
Best regards, 
Aleksandr

> On 23 Feb 2023, at 17:06, Kseniya Romanova  wrote:
> 
> The Project Management Committee (PMC) for Apache Ignite has invited
> Alexander Pakhomov to to become a committer and we are pleased to announce
> that he has accepted.
> 
> Alexander recently completed the IEP-87: Open API support for REST and
> continues developing IEP-88: CLI Tool, which includes many improvements,
> including dynamic completions and others. He is also active in dev
> discussions and was a speaker at the Ignite Summit.
> 
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
> 
> Please join me in welcoming Alexander, and congratulating him on the new
> role in the Apache Ignite Community!
> 
> Regards,
> Kseniya

RE: Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3

[Aleksandr Pakhomov]

Hi, 

I tend to agree with Roman. The separate todo with the linked ticket
should be enouth for now. 

--
Best regards, 
Aleksandr

On 2023/02/27 07:16:05 Roman Puchkovskiy wrote:
> Hi guys.
> 
> The thing is that we already use reactor-core transitively (it is a
> dependency of scalecube-cluster-api and scalecube-cluster). We also
> use it directly (in just a few places) in the networking code. If we
> shade the one that comes with the micronaut, the other one will still
> remain. We will probably need to shade all of them.
> 
> Even if we are going to do it, should we postpone such an aggressive
> shading till a later date? It seems that it might be easier to develop
> using the normal dependency model, without shading anything. We could
> add the corresponding TODOs and resolve them closer to the GA.
> 
> What do you think?
> 
> пт, 17 февр. 2023 г. в 13:46, Andrey Mashenkov :
> >
> > Hi Ivan,
> >
> > I'm ok to add reactive-streams.jar, because it contains just interfaces
> > that 1:1 java-flow API and FlowAdapter to convert JDK <-> ReactiveStreams
> > interfaces.
> >
> > The interfaces available in JDK >= 9 java.util.concurrent.Flow, are 1:1
> > > semantically equivalent to their respective Reactive Streams counterparts.
> > > This means that there will be a migratory period, while libraries move to
> > > adopt the new types in the JDK, however this period is expected to be 
> > > short
> > > - due to the full semantic equivalence of the libraries, as well as the
> > > Reactive Streams <-> Flow adapter library as well as a TCK compatible
> > > directly with the JDK Flow types.
> >
> >
> > However,  Project-reactor dependency (e.g. reactor.core.publisher.Flux) is
> > what we prefer to avoid or 'shadow' somehow.
> >
> >
> > On Fri, Feb 17, 2023 at 10:49 AM Ivan Gagarkin 
> > wrote:
> >
> > > There is a PR https://github.com/apache/ignite-3/pull/1569
> > >
> > > On Fri, Feb 17, 2023 at 11:47 AM Ivan Gagarkin 
> > > wrote:
> > >
> > > > The wrong link is above. It returns
> > > >
> > > https://www.reactive-streams.org/reactive-streams-1.0.3-javadoc/org/reactivestreams/Publisher.html
> > > >
> > > > On Fri, Feb 17, 2023 at 11:45 AM Ivan Gagarkin 
> > > > wrote:
> > > >
> > > >> We have to add reactor because we should implement
> > > >>
> > > https://github.com/micronaut-projects/micronaut-security/blob/master/security/src/main/java/io/micronaut/security/authentication/AuthenticationProvider.java
> > > >> which returns
> > > >>
> > > https://micronaut-projects.github.io/micronaut-security/2.4.0/api/io/micronaut/security/authentication/AuthenticationProvider.html
> > > .
> > > >> I don't see any implementations in the project right now.
> > > >>
> > > >> On Fri, Feb 3, 2023 at 6:18 PM Михаил Початкин  > > >
> > > >> wrote:
> > > >>
> > > >>> Hi, Ivan.
> > > >>>
> > > >>> I don't see any problems with adding *micronaut-security* in the
> > > context
> > > >>> of
> > > >>> the IGNITE-18575 epic of security implementation. Moreover, we already
> > > >>> have
> > > >>> several micronaut modules in dependencies (micronaut-inject,
> > > >>> micronaut-runtime, micronaut-validation, micronaut-http, etc) and I
> > > think
> > > >>> that we should not deviate from a single ecosystem. I would also like
> > > to
> > > >>> see the answer to Alexander's question about the reactor dependency.
> > > >>>
> > > >>> Thanks!
> > > >>>
> > > >>> пт, 3 февр. 2023 г. в 12:11, Aleksandr Pakhomov :
> > > >>>
> > > >>> > Hi Ivan,
> > > >>> >
> > > >>> > Why do we add reactor dependency? The Ignite 3 codebase
> > > >>> > uses java async API. Just wonder to know it we could escape
> > > >>> > the usage of third party async libraries.
> > > >>> >
> > > >>> > --
> > > >>> > Best regards,
> > > >>> > Aleksandr
> > > >>> >
> > > >>> > > On 3 Feb 2023, at 10:51, Ivan Gagarkin 
> > > >>> wrote:
> > > >>> > >
> > > >>> > > I'd like to add a few 3rd party libraries to Ignite 3
> > > >>> > >
> > > >>> > >   1. Micronaut Security
> > > >>> > >
> > > >>> https://micronaut-projects.github.io/micronaut-security/latest/guide/
> > > >>> > >   2. Micronaut Reactor
> > > >>> > >
> > > >>> https://micronaut-projects.github.io/micronaut-reactor/latest/guide/
> > > >>> > >
> > > >>> > > We have to have them for authentication and authorization in the
> > > >>> REST.
> > > >>> > > https://issues.apache.org/jira/browse/IGNITE-18576
> > > >>> > >
> > > >>> > > WDYT? Any objections? Also, comments on IEP-87 are welcomed.
> > > >>> > > --
> > > >>> > > Best Regards, Ivan
> > > >>> >
> > > >>> >
> > > >>>
> > > >>> --
> > > >>> С уважением,
> > > >>> Початкин Михаил.
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Best Regards, Ivan
> > > >>
> > > >
> > > >
> > > > --
> > > > Best Regards, Ivan
> > > >
> > >
> > >
> > > --
> > > Best Regards, Ivan
> > >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> 

Re: [DISCUSSION] IEP-105: SSL&TLS in Apache Ignite 3

[Aleksandr Pakhomov]

Hi Mikhail, 

I have a question:  Configuration snippets are just snippets or a list of all 
configration keys? 

--
Best regards, 
Aleksandr


> On 31 May 2023, at 09:32, Mikhail Pochatkin  wrote:
> 
> Hi, Igniters!
> 
> Please take a look at the proposal for SSL&TLS in Apache Ignite 3 [1].
> 
> Thanks for any feedback!
> 
> 1. IEP-105: SSL&TLS - Apache Ignite - Apache Software Foundation
> 

Re: [DISCUSSION] IEP-105: Basic Authentication in Apache Ignite 3

[Aleksandr Pakhomov]

Hi, Mikhail 

> Then the REST client’s exchange with the node will follow the flow:
> Client posts the client-id and client-secret to the token endpoint URL using 
> specified authentication type and receives an access token or error message. 
> At this point implementation should cache the token.
> Client sends the access token to the REST API endpoint using the 
> client_secret_basic authentication type.
> REST API implementation validates the token using the JWKS URL.
> 

^^ does not sound like a Basic Authentication that is used to be just a base64 
encoded username-password pair. Shall we rename the proposal to "Authentication 
in Apache Ignite 3"? 

One more question, could you please describe the security-related about how 
should we store the password on the server? 

-- 
Best regards, 
Aleksandr


> On 31 May 2023, at 09:34, Mikhail Pochatkin  wrote:
> 
> Hi, Igniters!
> 
> Please take a look at the proposal for Basic Authentication in Apache
> Ignite 3 [1].
> 
> Thanks for any feedback!
> 
> 1. IEP-106: Basic Authentication - Apache Ignite - Apache Software
> Foundation
> 

Re: New Apache Ignite PMC member: Nikita Amelchev

[Aleksandr Pakhomov]

Congratulations! 


> On 21 Nov 2023, at 18:18, Dmitriy Pavlov  wrote:
> 
> Hello Igniters,
> 
> The Project Management Committee (PMC) for Apache Ignite
> has invited Nikita Amelchev to become a member of PMC and we are pleased
> to announce that he has accepted.
> 
> We appreciate his constant efforts in improving Apache Ignite code, as well
> as efforts in preparing 2 major releases.
> 
> A PMC member helps manage and guide the direction of the project.
> 
> Congratulations on your new role! Keep the pace!
> 
> Best Regards
> Dmitriy Pavlov
> on behalf of Apache Ignite PMC

[DISCUSSION] IEP-124: User Object Serialization

[Aleksandr Pakhomov]

Hi, dear community. 

I would like to propose the design for supporting user objects in 
Ignite 3. All APIs that can accept/return custom objects that are 
not a part of Ignite 3 distribution are going to have additional 
parameter -- argument/result marshaller. 

I would appreciate any feedback, feel free to reply to this 
message or leave the comment in the Confluence. 

https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization

--
Best regards,
Aleksandr Pakhomov
 

Re: [DISCUSSION] IEP-124: User Object Serialization

[Aleksandr Pakhomov]

Thanks for the question, Aleksandr. Can you clarify what do you mean by 
existing User Object Serialization protocol? Am I right assuming that you 
are talking about Mappers that are supported in Record and KV APIs? 

--
Best regards,
Aleksandr Pakhomov

> On 11 Jul 2024, at 18:39, Aleksandr Polovtsev  wrote:
> 
> Hi, Aleksandr, thank you for the great effort! 
> 
> Could you please explain how this protocol differs from the existing User 
> Object Serialization protocol? Why do we need another one?
> 
> On Thu, Jul 11, 2024 at 6:20 PM Aleksandr Pakhomov  <mailto:apk...@gmail.com>> wrote:
>> Hi, dear community. 
>> 
>> I would like to propose the design for supporting user objects in 
>> Ignite 3. All APIs that can accept/return custom objects that are 
>> not a part of Ignite 3 distribution are going to have additional 
>> parameter -- argument/result marshaller. 
>> 
>> I would appreciate any feedback, feel free to reply to this 
>> message or leave the comment in the Confluence. 
>> 
>> IEP-124: User Object Serialization - Apache Ignite - Apache Software 
>> Foundation
>> cwiki.apache.org
>> 
>>  
>> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization>IEP-124:
>>  User Object Serialization - Apache Ignite - Apache Software Foundation 
>> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization>
>> cwiki.apache.org 
>> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization>
>> 
>> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization>
>> 
>> --
>> Best regards,
>> Aleksandr Pakhomov
>>  
> 
> 
> --
> With regards,
> Aleksandr Polovtsev

Re: [DISCUSSION] IEP-124: User Object Serialization

[Aleksandr Pakhomov]

I see, we have to support not only Java classes but all 
platforms (C++, Python, C#). So we can not use the 
protocol from internal networking. 

From the link you shared:
"User object serialization must follow Java Serialization API contracts"

--
Best regards,
Aleksandr Pakhomov

> On 11 Jul 2024, at 18:55, Aleksandr Polovtsev  wrote:
> 
> No, I'm talking about the protocol described here:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-67%3A+Networking+module#IEP67:Networkingmodule-UserObjectSerialization
> 
> On Thu, Jul 11, 2024 at 6:47 PM Aleksandr Pakhomov  <mailto:apk...@gmail.com>> wrote:
> 
>> Thanks for the question, Aleksandr. Can you clarify what do you mean by
>> existing User Object Serialization protocol? Am I right assuming that you
>> are talking about Mappers that are supported in Record and KV APIs?
>> 
>> --
>> Best regards,
>> Aleksandr Pakhomov
>> 
>>> On 11 Jul 2024, at 18:39, Aleksandr Polovtsev 
>> wrote:
>>> 
>>> Hi, Aleksandr, thank you for the great effort!
>>> 
>>> Could you please explain how this protocol differs from the existing
>> User Object Serialization protocol? Why do we need another one?
>>> 
>>> On Thu, Jul 11, 2024 at 6:20 PM Aleksandr Pakhomov > <mailto:apk...@gmail.com>> wrote:
>>>> Hi, dear community.
>>>> 
>>>> I would like to propose the design for supporting user objects in
>>>> Ignite 3. All APIs that can accept/return custom objects that are
>>>> not a part of Ignite 3 distribution are going to have additional
>>>> parameter -- argument/result marshaller.
>>>> 
>>>> I would appreciate any feedback, feel free to reply to this
>>>> message or leave the comment in the Confluence.
>>>> 
>>>> IEP-124: User Object Serialization - Apache Ignite - Apache Software
>> Foundation
>>>> cwiki.apache.org <http://cwiki.apache.org/>
>>>> 
>>>> <
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization>IEP-124:
>> User Object Serialization - Apache Ignite - Apache Software Foundation <
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization
>>> 
>>>> cwiki.apache.org <http://cwiki.apache.org/> <
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization>
>>  <
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-124%3A+User+Object+Serialization
>>> 
>>>> 
>>>> --
>>>> Best regards,
>>>> Aleksandr Pakhomov
>>>> 
>>> 
>>> 
>>> --
>>> With regards,
>>> Aleksandr Polovtsev
>> 
>> 
> 
> -- 
> With regards,
> Aleksandr Polovtsev