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 
>>> 
>>> [3] 
>>> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>>>  
>>> 
>>> [4] 
>>> https://www.timeanddate.com/countdown/generic?iso=20220527T21=166=%5BVOTE%5D+Add+micronaut+dependency+to+Ignite+3=cursive

Re: [DISCUSSION] IEP-89: PITR

[Maksim Timonin]

Hi Roman,

Thanks for your comments! Yes, at the beginning I considered using a single
class for two types of records. But it is confusing, as you're correctly
noticed. I reworked IEP, now there are 2 different classes, and both
contain a list of transactions to include. Also I added info about when
those WAL records are actually written to 'WAL records' sections. Please,
have a look.

Thanks,
Maksim

On Thu, May 26, 2022 at 2:54 PM Roman Puchkovskiy <
roman.puchkovs...@gmail.com> wrote:

> Hi Maksim.
>
> Do I understand correctly that 'consistent cut start' message always
> contains IDs of transactions to include, while 'consistent cut finish'
> message always contains IDs of transactions to exclude from the
> consistent cut? (At least, this is the impression I got from the
> example of parsing the WAL and the accompanying figure). If this is
> the case, then it looks like the `include` and `check` fields are
> mutually exclusive in ConsistentCutRecord. Would it make sense to
> replace it with two classes, like ConsistentCutStartRecord(cutVer,
> include) and ConsistentCutFinishRecord(cutVer, exclude)?
>
> Also, it seems that it could be beneficial to have a separate section
> explaining when the corresponding records are written to WAL, to make
> this information easier to find. Or, maybe, this could be added to the
> current 'WAL records' section.
>
> пн, 16 мая 2022 г. в 12:52, Maksim Timonin :
> >
> > Dear Igniters,
> >
> > I just published IEP-89 [1] that proposes a new feature to Ignite -
> (point
> > in time recovery) PITR. I propose to implement the Consistent Cut
> algorithm
> > for this, actually I achieved a working PoC for Ignite. And based on my
> > research I wrote this IEP.
> >
> > Let's start a discussion here. Any questions or comments are welcomed.
> >
> > Thanks!
> >
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314
>

Re: [VOTE] Add micronaut dependency to Ignite 3

[Andrey Gura]

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 
> > 
> > [3] 
> > https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
> >  
> > 
> > [4] 
> > https://www.timeanddate.com/countdown/generic?iso=20220527T21=166=%5BVOTE%5D+Add+micronaut+dependency+to+Ignite+3=cursive

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

[Andrey Gura]

Hi,

Hmmm... It seems that [2] is just a marketing page that doesn't give
any arguments about the micronaut.

Anyway, security is a good point. Aleksandr, could you please add some
note to the IEP about security related value of the micronaut
framework?





On Thu, May 26, 2022 at 9:48 AM Mikhail Pochatkin
 wrote:
>
> Hello Igniters.
>
> I see that the main argument against Micronaut is that we need
> Micronaut+Swagger to achieve IEP 87 if we can use only Swagger. I agree
> this is a valid point and logically. But I think we can take a look into it
> from another side, from future vision. Main idea to start using micronaut
> to simplify code writing in future just because Micronaut Framework really
> helps to develop REST services in practice. For example, I think it's
> obvious that Ignite will need to implement some authentication mechanism
> and Micronaut can help to achieve it [1]. Moreover Micronaut is based on
> the same technology which is currently used in Ignite, I mean Netty. It
> means that we should speak only about vulnerabilities inside of Micronaut
> implementation, but the Micronaut project has a very big community and a
> lot of clients. In context of it I would say that bugs and vulnerabilities
> in Micronaut implementation will be found more quickly than in internal
> Ignite implementation with pure Netty. Another point about cloud native
> support [2] which also can be useful in the context of Ignite.
>
> [1] https://micronaut-projects.github.io/micronaut-security/latest/guide/
> [2] https://objectcomputing.com/expertise/cloud-engineering
>
> On Wed, May 25, 2022 at 6:45 PM Andrey Gura  wrote:
>
> > Why couldn't the handlers be annotated?
> >
> > I think Kirill Gusakov (as the feature contributor) can give some
> > ideas about what and how should be annotated. This may require some
> > tweaking.
> >
> > On Wed, May 25, 2022 at 6:06 PM Aleksandr Pakhomov 
> > wrote:
> > >
> > > 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 <
> > alexpolovt...@gmail.com>
> > > >> 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] 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: [DISCUSSION] IEP-88: CLI Tool

[Roman Puchkovskiy]

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: [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

[Roman Puchkovskiy]

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