Re: [VOTE] Add swagger dependency to Ignite 3

[Ivan Pavlukhin]

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: [VOTE] Add swagger dependency to Ignite 3

[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: [VOTE] Add swagger dependency to Ignite 3

[Alexander Polovtcev]

+1 from me, I've seen many projects using this approach and I personally
find it quite useful

On Wed, May 25, 2022 at 5:54 PM Andrey Gura  wrote:

> Ilya,
>
> are there any alternatives to Swagger that you could recommend that
> don't have the mentioned drawback?
>
> It seems that OPen API itself doesn't define primitive and wrapped
> types because such information is language/runtime/etc specific. Maybe
> this problem will be addressed in the future.
>
> On Mon, May 23, 2022 at 8:55 PM Ilya Kasnacheev
>  wrote:
> >
> > Hello!
> >
> > Back when I looked at it, Swagger was very primitive, such as not
> > supporting primitive types in generated models
> > https://stackoverflow.com/a/45053804/36498
> >
> > I'm not sure it is the right tool, please clarify why it is needed.
> >
> > -0.5 from me (binding)
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 23 мая 2022 г. в 19:57, 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 <
> > > https://www.apache.org/foundation/voting.html>
> > > [3]
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
>


-- 
With regards,
Aleksandr Polovtcev

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

[Andrey Gura]

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

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

[Andrey Gura]

Agree with Alexander. I ask the same question in the vote thread.

On Wed, May 25, 2022 at 5:47 PM 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?
> >
> >
>
> --
> With regards,
> Aleksandr Polovtcev

Re: [VOTE] Add swagger dependency to Ignite 3

[Andrey Gura]

Ilya,

are there any alternatives to Swagger that you could recommend that
don't have the mentioned drawback?

It seems that OPen API itself doesn't define primitive and wrapped
types because such information is language/runtime/etc specific. Maybe
this problem will be addressed in the future.

On Mon, May 23, 2022 at 8:55 PM Ilya Kasnacheev
 wrote:
>
> Hello!
>
> Back when I looked at it, Swagger was very primitive, such as not
> supporting primitive types in generated models
> https://stackoverflow.com/a/45053804/36498
>
> I'm not sure it is the right tool, please clarify why it is needed.
>
> -0.5 from me (binding)
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 23 мая 2022 г. в 19:57, 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 <
> > https://www.apache.org/foundation/voting.html>
> > [3]
> > https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries

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

[Alexander Polovtcev]

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

-- 
With regards,
Aleksandr Polovtcev

Re: [VOTE] Add micronaut dependency to Ignite 3

[Andrey Gura]

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

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

The problem is not the scan frequency. The actual problem is the
release cycle: somebody should fix a vulnerability in some dependency,
then that dependency should be released and in the end Ignite should
refresh dependencies and then should be released.

In absence of dependencies we just fix the problem and build a
maintenance release.

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

>From my point of view this is a bogus problem. Of course the described
situation is possible and often happens. But the presence of a
generation step does not protect against problems on other levels. I
can describe the interface correctly but implementation of this
interface can be wrong. So such instruments give just an illusion of
correctness. Where is the truth? In fact, no one knows.

On Fri, May 20, 2022 at 3:39 PM Aleksandr Pakhomov  wrote:
>
> 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] IEP-88: CLI Tool

[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: [DISCUSS] Query API for Ignite 3.0

[Andrey Gura]

Andrey,

there is no IEP for Java API for SQL and would be great to have it.
I'll create the IEP soon.

On Fri, May 20, 2022 at 1:56 PM Andrey Mashenkov
 wrote:
>
> JFYI. we have merged the initial version of SQL public API [1] and are
> going to implement it in epic [2] and I've created few tickets on this.
>
> Andey Gura, Taras Ledkov, Konstantine Orlov would you mind to share your
> thoughts on implementation part in some IEP?
> Is there IEP page created on the topic?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-15212
> [2] https://issues.apache.org/jira/browse/IGNITE-16952
>
> On Tue, Apr 6, 2021 at 4:23 PM Andrey Mashenkov 
> wrote:
>
> > Hi Taras.
> >
> > 1. AFAIK, only Thin clients will be available in 3.0.
> > However, yes, Native JDBC API is still "must have" on servers.
> >
> > 2. We won't have other projects in dependencies if possible. Unless
> > we/they are Jigsaw compatible though.
> >
> > 2.1  I think it makes sense to be an R2DBC-compatible as it is a widely
> > used framework. E.g. Spring supports R2DBC [1].
> > Having an extension with R2DBC support will make Spring integration with
> > Ignite easy in the future.
> >
> > If it will be enough to have a dependency on just reactive-streams API [2],
> > then adding this API to dependencies looks ok to me, as there are only a
> > few interfaces and converters to/from JDK Flow API.
> > And the question is would we go with Flow API or Reactive-Streams?
> >
> > If we need some more than reactive-streams API, then I would suggest to go
> > with Flow API.
> >
> > 2.2 ADBA is compatible with R2DBC but was discontinued [3].
> >
> > 2.3 I don't think custom API is ever useful. We will need
> > converters/adapters to Flow or Reactive-streams for easy integration with
> > other APIs/frameworks.
> > Otherwise, uses will have difficulties interacting with Ignite in a
> > reactive way.
> >
> > [1]
> > https://spring.io/blog/2018/12/07/reactive-programming-and-relational-databases
> > [2] https://github.com/reactive-streams/reactive-streams-jvm
> > [3]
> > https://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2019-September/000529.html
> >
> > On Tue, Apr 6, 2021 at 3:05 PM Taras Ledkov  wrote:
> >
> >> Hi,
> >>
> >> Ignite 3.0 requires a rethinking of the query API.
> >> We have 'cache.query()' and 'SqlFieldQuery' abstractions at the Ignite
> >> 2.x native API and several JDBC implementation for clients.
> >>
> >> I propose to think about new query/SQL API for the Ignite 3.0.
> >>
> >> My vision is something like this:
> >> Ignite will support two query APIs: standard JDBC (on native) and one of
> >> reactive DB API.
> >>
> >> 1. Native JDBC API, e.g.:
> >>  Connection conn = node.sql().connection(props);
> >>
> >> JDBC is the industrial standard of the DB access and we have to support
> >> one.
> >> Also:
> >> 1.1. Thin JDBC client will be really thin: provide network communication
> >> layer and transparently map to native API.
> >> 1.2. Thick JDBC client implementation will be trivial: start client node
> >> and open JDBC connection on the started node.
> >> 1.3. JDBC provides sufficient functionality to implement ODBC (need to
> >> investigate: may be thin protocol may be extended to unify JDBC and ODBC).
> >>
> >> 2. About reactive DB API.
> >> I don't know of any industrial standard API for DB reactive access now.
> >> There are several candidates:
> >> 2.1. R2DBC look like the popular and alive. See [1];
> >> 2.2. ADBA (java.sql2 [2]) looks like not alive. Not sure;
> >> 2.3. Custom async/reactive API.
> >> e.g. oracle DB use this way [3].
> >>
> >> Igniters, WDYT?
> >>
> >> [1]. https://github.com/r2dbc/r2dbc-spi
> >> [2].
> >> http://cr.openjdk.java.net/~lancea/apidoc/java/sql2/package-summary.html
> >> [3].
> >>
> >> https://docs.oracle.com/en/database/oracle/oracle-database/21/jjdbc/jdbc-reactive-extensions.html#GUID-1C40C43B-3823-4848-8B5A-D2F97A82F79B
> >>
> >> --
> >> Taras Ledkov
> >> Mail-To: tled...@gridgain.com
> >>
> >>
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov

[MTCGA]: new failures in builds [6451463] needs to be handled

[ignitetcbot]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New Critical Failure in master Geospatial Indexing 
https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_GeospatialIndexing?branch=%3Cdefault%3E
 Changes may lead to failure were done by 
 - osipov.v.ale 
https://ci2.ignite.apache.org/viewModification.html?modId=954363
 - osipov.v.ale 
https://ci2.ignite.apache.org/viewModification.html?modId=954361
 - maxim muzafarov  
https://ci2.ignite.apache.org/viewModification.html?modId=954405
 - igor sapego  
https://ci2.ignite.apache.org/viewModification.html?modId=954371

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 06:23:19 25-05-2022