Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Ilya Kasnacheev]

Hello!

Can you arrange that?

Regards,
-- 
Ilya Kasnacheev


чт, 19 мая 2022 г. в 09:20, Maxim Muzafarov :

> Ilya,
>
> Should we start a formal vote about the ignite-schedule deletion?
>
> On Mon, 16 May 2022 at 14:28, Ilya Kasnacheev 
> wrote:
> >
> > Hello!
> >
> > In my opinion, the ignite-schedule module needs to be dropped - it has
> bad
> > API, outdated GPL dependency and in general is out of focus of Ignite.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 13 мая 2022 г. в 17:51, Maxim Muzafarov :
> >
> > > Folks,
> > >
> > > I've found that the following modules are rarely used and haven't been
> > > change for a few years, but  they are released each time Ignite being
> > > released. It seems we can safely move all of them to the Extensions
> > > project.
> > >
> > > The list:
> > > - ignite-yarn
> > > - ignite-geospatial
> > > - ignite-schedule
> > >
> > > WDYT?
> > >
>

Re: IEP-90 Ignite 3 Client Lifecycle

[Igor Sapego]

Andrey,

1. If a server generates a UUID that already exists it can check and just
re-generate it straight away
as a check is just a simple map lookup.

2. Well, yes. This proposal does not consider monitoring, but with current
approach it will be definitely
easier to implement it properly.

Pavel,

Wow, that's really cool that you've already started working on it.

Regarding your proposal I like it - it will really make a procedure easier
and faster for a client. I'll change
the IEP accordingly.

Best Regards,
Igor


On Thu, May 19, 2022 at 11:40 PM Pavel Tupitsyn 
wrote:

> Igor,
>
> I've started working on the initial sessions implementation [1],
> and I'd like to clarify the procedure of logical connection restore.
>
> > client in its turn tries to establish a new *node connection*
> > and restore *logical connection *using ConnectionRestoreReq
>
> This implies either an additional request, or something that replaces
> normal handshake.
> However, we need to handle two cases here:
> - Logical connection is restored
> - Logical connection is not restored (timed out, server restarted, etc), in
> which case we still establish the connection and use it.
>
> To account for the second case, we should always start with a regular
> handshake.
> I propose to add a nullable UUID field to the handshake request to cover
> both cases:
> - connectionId is null or not found on server: proceed with normal
> handshake, return newly generated connectionId.
> - connectionId is not null and found on server: restore logical connection,
> return the same connectionId
>
> Client checks if returned connectionId equals to the original and
> understands whether logical connection was restored or not.
>
> Thoughts?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-16928
>
> On Thu, May 19, 2022 at 10:27 PM Pavel Tupitsyn 
> wrote:
>
> > Andrey,
> >
> > > different connections on different client instances theoretically
> > > could generate an already existing connection ID
> >
> > Do you mean an UUID collision?
> >
> > On Thu, May 19, 2022 at 1:09 AM Andrey Gura  wrote:
> >
> >> Igor,
> >>
> >> Thanks for the proposal.
> >>
> >> I understand that such a situation is almost impossible but "if
> >> anything can go wrong, it will". Does the protocol take into account
> >> that different connections on different client instances theoretically
> >> could generate an already existing connection ID?
> >>
> >> Also, do I understand correctly that a server has enough information
> >> about client connections so it will be possible to observe a
> >> connections list on the server? It would be useful for cluster
> >> monitoring purposes.
> >>
> >> On Tue, May 17, 2022 at 3:11 PM Igor Sapego  wrote:
> >> >
> >> > 1. I've tried to clarify IDs part;
> >> > 2. Maybe you are right, though in this case we'd need to use
> >> authentication
> >> > in ConnectionRestoreReq. Which sounds reasonable to me.
> >> >
> >> > Best Regards,
> >> > Igor
> >> >
> >> >
> >> > On Tue, May 17, 2022 at 10:47 AM Pavel Tupitsyn  >
> >> > wrote:
> >> >
> >> > > Igor,
> >> > >
> >> > > The proposal looks good to me. Very detailed!
> >> > >
> >> > > A couple comments:
> >> > >
> >> > > 1. There is a bit of a term mixup with "Connection ID", "Node ID",
> >> "Token"
> >> > > - can you please review those?
> >> > >
> >> > > 2. > The Connection ID should be generated using a proper secure
> >> algorithm
> >> > > (additional research is required here) to make sure an intruder can
> >> not
> >> > > generate an existing Connection ID
> >> > > Not sure about the reasoning here. I think randomUUID() should be
> >> enough:
> >> > > - In the case of an unsecured cluster it does not matter, because
> >> anyone
> >> > > can do anything.
> >> > > - In the case of a secured cluster it does not matter, because
> >> > > authentication/authorization keeps intruders out.
> >> > >
> >> > >
> >> > > On Mon, May 16, 2022 at 11:07 PM Igor Sapego 
> >> wrote:
> >> > >
> >> > > > Hi, Igniters
> >> > > >
> >> > > > I've prepared an IEP for Ignite 3 Client Lifecycle [1]. The main
> >> idea is
> >> > > to
> >> > > > define client lifecycle as well as core algorithms and mechanisms
> >> used by
> >> > > > clients. This proposal can be used as a reference for
> >> implementation of a
> >> > > > new client for Ignite when dealing with such problems as:
> >> > > >
> >> > > >- Resolving of user-provided addresses;
> >> > > >- Initial connection to a cluster;
> >> > > >- Maintaining cluster connection;
> >> > > >- Connection recovery;
> >> > > >- Connection break handling.
> >> > > >
> >> > > > So take a look and let me know what you think guys.
> >> > > >
> >> > > > [1] -
> >> > > >
> >> > >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle
> >> > > >
> >> > > > Best Regards,
> >> > > > Igor
> >> > > >
> >> > >
> >>
> >
>

Re: IEP-90 Ignite 3 Client Lifecycle

[Pavel Tupitsyn]

Igor,

I've started working on the initial sessions implementation [1],
and I'd like to clarify the procedure of logical connection restore.

> client in its turn tries to establish a new *node connection*
> and restore *logical connection *using ConnectionRestoreReq

This implies either an additional request, or something that replaces
normal handshake.
However, we need to handle two cases here:
- Logical connection is restored
- Logical connection is not restored (timed out, server restarted, etc), in
which case we still establish the connection and use it.

To account for the second case, we should always start with a regular
handshake.
I propose to add a nullable UUID field to the handshake request to cover
both cases:
- connectionId is null or not found on server: proceed with normal
handshake, return newly generated connectionId.
- connectionId is not null and found on server: restore logical connection,
return the same connectionId

Client checks if returned connectionId equals to the original and
understands whether logical connection was restored or not.

Thoughts?

[1] https://issues.apache.org/jira/browse/IGNITE-16928

On Thu, May 19, 2022 at 10:27 PM Pavel Tupitsyn 
wrote:

> Andrey,
>
> > different connections on different client instances theoretically
> > could generate an already existing connection ID
>
> Do you mean an UUID collision?
>
> On Thu, May 19, 2022 at 1:09 AM Andrey Gura  wrote:
>
>> Igor,
>>
>> Thanks for the proposal.
>>
>> I understand that such a situation is almost impossible but "if
>> anything can go wrong, it will". Does the protocol take into account
>> that different connections on different client instances theoretically
>> could generate an already existing connection ID?
>>
>> Also, do I understand correctly that a server has enough information
>> about client connections so it will be possible to observe a
>> connections list on the server? It would be useful for cluster
>> monitoring purposes.
>>
>> On Tue, May 17, 2022 at 3:11 PM Igor Sapego  wrote:
>> >
>> > 1. I've tried to clarify IDs part;
>> > 2. Maybe you are right, though in this case we'd need to use
>> authentication
>> > in ConnectionRestoreReq. Which sounds reasonable to me.
>> >
>> > Best Regards,
>> > Igor
>> >
>> >
>> > On Tue, May 17, 2022 at 10:47 AM Pavel Tupitsyn 
>> > wrote:
>> >
>> > > Igor,
>> > >
>> > > The proposal looks good to me. Very detailed!
>> > >
>> > > A couple comments:
>> > >
>> > > 1. There is a bit of a term mixup with "Connection ID", "Node ID",
>> "Token"
>> > > - can you please review those?
>> > >
>> > > 2. > The Connection ID should be generated using a proper secure
>> algorithm
>> > > (additional research is required here) to make sure an intruder can
>> not
>> > > generate an existing Connection ID
>> > > Not sure about the reasoning here. I think randomUUID() should be
>> enough:
>> > > - In the case of an unsecured cluster it does not matter, because
>> anyone
>> > > can do anything.
>> > > - In the case of a secured cluster it does not matter, because
>> > > authentication/authorization keeps intruders out.
>> > >
>> > >
>> > > On Mon, May 16, 2022 at 11:07 PM Igor Sapego 
>> wrote:
>> > >
>> > > > Hi, Igniters
>> > > >
>> > > > I've prepared an IEP for Ignite 3 Client Lifecycle [1]. The main
>> idea is
>> > > to
>> > > > define client lifecycle as well as core algorithms and mechanisms
>> used by
>> > > > clients. This proposal can be used as a reference for
>> implementation of a
>> > > > new client for Ignite when dealing with such problems as:
>> > > >
>> > > >- Resolving of user-provided addresses;
>> > > >- Initial connection to a cluster;
>> > > >- Maintaining cluster connection;
>> > > >- Connection recovery;
>> > > >- Connection break handling.
>> > > >
>> > > > So take a look and let me know what you think guys.
>> > > >
>> > > > [1] -
>> > > >
>> > >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle
>> > > >
>> > > > Best Regards,
>> > > > Igor
>> > > >
>> > >
>>
>

Re: IEP-90 Ignite 3 Client Lifecycle

[Pavel Tupitsyn]

Andrey,

> different connections on different client instances theoretically
> could generate an already existing connection ID

Do you mean an UUID collision?

On Thu, May 19, 2022 at 1:09 AM Andrey Gura  wrote:

> Igor,
>
> Thanks for the proposal.
>
> I understand that such a situation is almost impossible but "if
> anything can go wrong, it will". Does the protocol take into account
> that different connections on different client instances theoretically
> could generate an already existing connection ID?
>
> Also, do I understand correctly that a server has enough information
> about client connections so it will be possible to observe a
> connections list on the server? It would be useful for cluster
> monitoring purposes.
>
> On Tue, May 17, 2022 at 3:11 PM Igor Sapego  wrote:
> >
> > 1. I've tried to clarify IDs part;
> > 2. Maybe you are right, though in this case we'd need to use
> authentication
> > in ConnectionRestoreReq. Which sounds reasonable to me.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, May 17, 2022 at 10:47 AM Pavel Tupitsyn 
> > wrote:
> >
> > > Igor,
> > >
> > > The proposal looks good to me. Very detailed!
> > >
> > > A couple comments:
> > >
> > > 1. There is a bit of a term mixup with "Connection ID", "Node ID",
> "Token"
> > > - can you please review those?
> > >
> > > 2. > The Connection ID should be generated using a proper secure
> algorithm
> > > (additional research is required here) to make sure an intruder can not
> > > generate an existing Connection ID
> > > Not sure about the reasoning here. I think randomUUID() should be
> enough:
> > > - In the case of an unsecured cluster it does not matter, because
> anyone
> > > can do anything.
> > > - In the case of a secured cluster it does not matter, because
> > > authentication/authorization keeps intruders out.
> > >
> > >
> > > On Mon, May 16, 2022 at 11:07 PM Igor Sapego 
> wrote:
> > >
> > > > Hi, Igniters
> > > >
> > > > I've prepared an IEP for Ignite 3 Client Lifecycle [1]. The main
> idea is
> > > to
> > > > define client lifecycle as well as core algorithms and mechanisms
> used by
> > > > clients. This proposal can be used as a reference for implementation
> of a
> > > > new client for Ignite when dealing with such problems as:
> > > >
> > > >- Resolving of user-provided addresses;
> > > >- Initial connection to a cluster;
> > > >- Maintaining cluster connection;
> > > >- Connection recovery;
> > > >- Connection break handling.
> > > >
> > > > So take a look and let me know what you think guys.
> > > >
> > > > [1] -
> > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > >
>

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

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] 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 /
> [4] 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] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Alexander Polovtcev]

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 /
> >>> [4] 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] 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 /
>>> [4] https://swagger.io 
>>> [5]
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
>> <
>> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
>>> /
>> 

Final reminder: ApacheCon North America call for presentations closing soon

[Rich Bowen]

[Note: You're receiving this because you are subscribed to one or more
Apache Software Foundation project mailing lists.]

This is your final reminder that the Call for Presetations for
ApacheCon North America 2022 will close at 00:01 GMT on Monday, May
23rd, 2022. Please don't wait! Get your talk proposals in now!

Details here: https://apachecon.com/acna2022/cfp.html

--Rich, for the ApacheCon Planners

Re: [DISCUSSION] IEP-88: CLI Tool

[Ilya Korol]

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] 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] IEP-87: Open API support for REST

[Roman Puchkovskiy]

Oops, sent it too early :) I'll proceed.

... As a side note, as far as I know, there were some discussions
about using automatic dependency injection in Ignite 3 (as the whole
system), but no decision was made.

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

чт, 19 мая 2022 г. в 11:12, Roman Puchkovskiy :
>
> 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?
>
> 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
>
> чт, 12 мая 2022 г. в 23:22, 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
> >  
> > 
> >
> >
> > > 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
> >

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

[Roman Puchkovskiy]

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?

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

чт, 12 мая 2022 г. в 23:22, 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
>  
> 
>
>
> > 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
>

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Maxim Muzafarov]

Folks,

Let's extend a bit the list of modules for moving to the Ignite Extensions.

The list:

- ignite-yarn
- ignite-geospatial
- ignite-mesos
- ignite-cloud
- ignite-osgi*
- ignite-schedule (deletion proposed)

On Thu, 19 May 2022 at 09:20, Maxim Muzafarov  wrote:
>
> Ilya,
>
> Should we start a formal vote about the ignite-schedule deletion?
>
> On Mon, 16 May 2022 at 14:28, Ilya Kasnacheev  
> wrote:
> >
> > Hello!
> >
> > In my opinion, the ignite-schedule module needs to be dropped - it has bad
> > API, outdated GPL dependency and in general is out of focus of Ignite.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 13 мая 2022 г. в 17:51, Maxim Muzafarov :
> >
> > > Folks,
> > >
> > > I've found that the following modules are rarely used and haven't been
> > > change for a few years, but  they are released each time Ignite being
> > > released. It seems we can safely move all of them to the Extensions
> > > project.
> > >
> > > The list:
> > > - ignite-yarn
> > > - ignite-geospatial
> > > - ignite-schedule
> > >
> > > WDYT?
> > >

Re: [DISCUSSION] Move the ignite-yarn, ignite-geospatial, ignite-schedule to the Ignite Extensions

[Maxim Muzafarov]

Ilya,

Should we start a formal vote about the ignite-schedule deletion?

On Mon, 16 May 2022 at 14:28, Ilya Kasnacheev  wrote:
>
> Hello!
>
> In my opinion, the ignite-schedule module needs to be dropped - it has bad
> API, outdated GPL dependency and in general is out of focus of Ignite.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 13 мая 2022 г. в 17:51, Maxim Muzafarov :
>
> > Folks,
> >
> > I've found that the following modules are rarely used and haven't been
> > change for a few years, but  they are released each time Ignite being
> > released. It seems we can safely move all of them to the Extensions
> > project.
> >
> > The list:
> > - ignite-yarn
> > - ignite-geospatial
> > - ignite-schedule
> >
> > WDYT?
> >