ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Thu, 25 Jul 2019 20:24:29 GMT
Folks, I've seen that someone added Spark to the list of "Integrations for
Discontinuation". I wouldn't do this. IMO, Spark is one of the key
integrations along with Spring Data, TensorFlow, Kafka that should be moved
out of the core but to be supported by the community:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IgniteModules
<https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IgniteModules>
-
Denis


On Thu, Jul 25, 2019 at 1:21 AM Alexey Zinoviev <zaleslaw.sin@gmail.com>
wrote:

> Thanks for the clarification, will try to vote
>
> чт, 25 июл. 2019 г. в 04:11, Denis Magda <dmagda@gridgain.com>:
>
> > Alexey,
> >
> > I've changed format on the wiki so that every community member can cast
> +1
> > and -1 vote explaining his/her stance. This should help us to filter out
> > those integrations that everyone agrees to discontinue vs. those that are
> > controversial. Please, *everyone interested* share your opinion by
> putting
> > a name and +1/-1 in these tables:
> >
> >    - Integrations for discontinuation:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> >    - APIs for removal:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> >
> >
> >
> > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > > issues, but is I'd like this kind of index)
> >
> >
> > Both spatial and full-text search indexes provide limit support and not
> > integrated with Ignite's memory architecture. It's better for us to
> remove
> > them in Ignite 3.0 (that will go with a new API to be proposed soon by
> Alex
> > Goncharuk) and rebuild from scratch in 3.1/3.2.
> >
> >
> > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > > because I've ready to try support them (or dive in this question) I
> think
> > > no so many work to support them or move to the separate module like
> > > BigDataTools Integrations
> >
> >
> > Why don't we have them as separate Github projects that can be updated
> both
> > by the community members and independent developers? I just don't want
> this
> > to be a burden of the community to test and maintain it for every
> release.
> >
> > 3. Annotations based configuration of SQL - we should be careful with
> that,
> > > I suppose it's useful feature
> >
> >
> > Alex Goncharuk should propose a new API for 3.0 soon.
> >
> > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > > integration into one module for messaging support
> >
> >
> > I wouldn't do this because 3rd party MQs go with their own versions that
> > start conflicting over the time. For instance, we already have several
> > modules for Hibernate and Spring Data integrations. To fix that, we just
> > need to store integrations in separate repos and do forks if a new
> > conflicting version has to be supported but there is still significant
> > usage of the old one.
> >
> > --
> > Denis Magda
> >
> >
> > On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev <zaleslaw.sin@gmail.com>
> > wrote:
> >
> > > I have a few ideas, maybe somebody will support me
> > > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > > issues, but is I'd like this kind of index)
> > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > > because I've ready to try support them (or dive in this question) I
> think
> > > no so many work to support them or move to the separate module like
> > > BigDataTools Integrations
> > > 3. Annotations based configuration of SQL - we should be careful with
> > that,
> > > I suppose it's useful feature
> > > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > > integration into one module for messaging support
> > >
> > > What do you think guys?
> > >
> > > пн, 22 июл. 2019 г. в 22:51, Denis Magda <dmagda@apache.org>:
> > >
> > > > Igniters,
> > > >
> > > > I did the first run through the wishlist and selected integrations
> and
> > > APIs
> > > > for discontinuation. My suggestion would be to use IEP-36
> > > (Modularization)
> > > > page for the final list that we'll send to the user list for
> feedback:
> > > >
> > > >    - Integrations for discontinuation:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> > > >    - APIs for removal:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> > > >
> > > > Please check those lists and let us know if you have any arguments
> > > against
> > > > discontinuation/removal of X. Also, if you believe that something
> > listed
> > > in
> > > > the wishlist should be added to the EIP then let's discuss that.
> > > > Personally, I see the whishlist as a page with ideas while the IEP a
> > > final
> > > > plan for action.
> > > >
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <
> > daradurvs@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > I think all agreed items should be marked @Deprecated in the code
> > > > > base, so we will be able to remove them transparently for the
> > > > > end-users.
> > > > >
> > > > > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <vololo100@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > Alex,
> > > > > >
> > > > > > I already added a couple of items to wishlist [1].
> > > > > >
> > > > > > Yes, I agree that the process should be iterative. But I am
> > confused
> > > > > > on what stage we are in a current interation? I suppose that
> Denis
> > is
> > > > > > going to present a list of removal candidates which we as
> > developers
> > > > > > agreed on. And should not we have that list already available
> > > > > > somewhere as a document? Now I see an infromation scattered
in
> this
> > > > > > thread and the wishlist [1]. And it is not easy to me to realize
> > > where
> > > > > > we are now.
> > > > > >
> > > > > > [1]
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > > >
> > > > > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk <
> > > > > alexey.goncharuk@gmail.com>:
> > > > > > >
> > > > > > > Ivan,
> > > > > > >
> > > > > > > The list is not final, we can still discuss and add more
points
> > to
> > > be
> > > > > > > cleaned in 3.0. The more clear and understandable the API
will
> > be,
> > > > the
> > > > > > > better. This thread was intended to draft the removal scope
for
> > 3.0
> > > > > and to
> > > > > > > understand which portions will be definitely removed.
> > > > > > >
> > > > > > >
> > > > > > > ср, 17 июл. 2019 г. в 15:26, Павлухин Иван
<
> vololo100@gmail.com
> > >:
> > > > > > >
> > > > > > > > Also, I did not quite get the point about JSR107 (JCache).
> From
> > > > time
> > > > > > > > to time I see on user-list threads where Ignite is
used along
> > > with
> > > > > > > > Spring annotation-based cache integration. I suppose
it
> > requires
> > > > > > > > JCache interfaces. What is crucially wrong with supporting
> it?
> > > > > > > >
> > > > > > > > ср, 17 июл. 2019 г. в 15:19, Павлухин
Иван <
> > vololo100@gmail.com
> > > >:
> > > > > > > > >
> > > > > > > > > Folks,
> > > > > > > > >
> > > > > > > > > Sorry if I am repeating something. I checked
a page [1] and
> > > have
> > > > > not
> > > > > > > > > found several items.
> > > > > > > > > 1. I thought that there was an agreement of dropping
OLD
> > > service
> > > > > grid,
> > > > > > > > > was not it?
> > > > > > > > > 2. Also IndexingSpi seems to me as a candidate
for removal.
> > > > > > > > >
> > > > > > > > > Should I add those items to the page? Or is there
another
> > page
> > > > > > > > > containing items to be removed that we agreed
on?
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
> > > > > > > > >
> > > > > > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda
<
> dmagda@apache.org
> > >:
> > > > > > > > > >
> > > > > > > > > > Alex, Igniters, sorry for a delay. Got swamped
with other
> > > > duties.
> > > > > > > > > >
> > > > > > > > > > Does it wait till the next week? I'll make
sure to
> dedicate
> > > > some
> > > > > time
> > > > > > > > for
> > > > > > > > > > that. Or if we'd like to run faster then
I'll appreciate
> if
> > > > > someone
> > > > > > > > else
> > > > > > > > > > steps in and prepares a list this week.
I'll help to
> review
> > > and
> > > > > > > > solidify it.
> > > > > > > > > >
> > > > > > > > > > -
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 16, 2019 at 7:58 AM Alexey Goncharuk
<
> > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Denis,
> > > > > > > > > > >
> > > > > > > > > > > Are we ready to present the list to
the user list?
> > > > > > > > > > >
> > > > > > > > > > > вт, 2 июл. 2019 г. в 00:27,
Denis Magda <
> > dmagda@apache.org
> > > >:
> > > > > > > > > > >
> > > > > > > > > > > > I wouldn't kick off dozens of
voting discussions.
> > > Instead,
> > > > > the
> > > > > > > > content on
> > > > > > > > > > > > the wiki page needs to be cleaned
and rearranged.
> This
> > > will
> > > > > make
> > > > > > > > the
> > > > > > > > > > > > content readable and comprehensible.
I can do that.
> > > > > > > > > > > >
> > > > > > > > > > > > Next, let's ask the user community
for an opinion.
> > After
> > > > > reviewing
> > > > > > > > and
> > > > > > > > > > > > incorporating the latter we can
do one more dev list
> > > > > discussion
> > > > > > > > with the
> > > > > > > > > > > > last call for opinions. Next,
will be the voting
> time.
> > If
> > > > > there is
> > > > > > > > a
> > > > > > > > > > > > feature someone from the dev list
is against of
> > removing,
> > > > > then we
> > > > > > > > can
> > > > > > > > > > > start
> > > > > > > > > > > > a separate vote for it later.
But let's get into
> those
> > > > cases
> > > > > first.
> > > > > > > > > > > >
> > > > > > > > > > > > -
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Jul 1, 2019 at 1:47 AM
Dmitriy Pavlov <
> > > > > dpavlov@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > I propose each removal should
have separated formal
> > > vote
> > > > > thread
> > > > > > > > with
> > > > > > > > > > > > > consensus approval (since
it is code modification).
> > > > > > > > > > > > >
> > > > > > > > > > > > > This means a single binding
objection with
> > > justification
> > > > > is a
> > > > > > > > blocker
> > > > > > > > > > > for
> > > > > > > > > > > > > removal.
> > > > > > > > > > > > >
> > > > > > > > > > > > > We need separation to let
community members pick up
> > an
> > > > > > > > interesting
> > > > > > > > > > > topic
> > > > > > > > > > > > > from email subject. Not all
members reading
> carefully
> > > > each
> > > > > post
> > > > > > > > in
> > > > > > > > > > > > > mile-long threads.
> > > > > > > > > > > > >
> > > > > > > > > > > > > пн, 1 июл. 2019 г.
в 11:17, Anton Vinogradov <
> > > > > av@apache.org>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > +1 to email survey with
following types of votes
> > > > > > > > > > > > > > - silence (agree with
all proposed removals)
> > > > > > > > > > > > > > - we have to keep XXX
because ...
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > As a result, will gain
lists
> > > > > > > > > > > > > > "to be removed" - no
one objected
> > > > > > > > > > > > > > "can be removed" - single
objection
> > > > > > > > > > > > > > "should be kept" - multi
objections
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis or Dmitry Pavlov,
could you please lead
> this
> > > > > thread?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Sat, Jun 29, 2019
at 12:27 AM Denis Magda <
> > > > > > > > dmagda@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Alex,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I would do an email
survey to hear an opinion
> of
> > > why
> > > > > someone
> > > > > > > > > > > > believes a
> > > > > > > > > > > > > > > feature A has to
stay. It makes sense to ask
> > about
> > > > the
> > > > > APIs
> > > > > > > > to be
> > > > > > > > > > > > > removed
> > > > > > > > > > > > > > > as well as integrations
to go out of community
> > > > support
> > > > > [1]
> > > > > > > > in the
> > > > > > > > > > > > same
> > > > > > > > > > > > > > > thread.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Has everyone expressed
an opinion? If yes, I
> can
> > go
> > > > > ahead and
> > > > > > > > > > > format
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > wishlist page and
make it structured for the
> user
> > > > > thread.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html
> > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Jun 28,
2019 at 8:54 AM Alexey
> Goncharuk
> > <
> > > > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Anton, good
point.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Do you have
any idea how we can keep track of
> > the
> > > > > voting?
> > > > > > > > Should
> > > > > > > > > > > we
> > > > > > > > > > > > > > > launch
> > > > > > > > > > > > > > > > a google survey
or survey monkey? Voting by
> > > email?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > пт, 28 июн.
2019 г. в 11:24, Anton
> Vinogradov <
> > > > > > > > av@apache.org>:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Alexey,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thank's
for keeping an eye on page updates.
> > > > > > > > > > > > > > > > > Near
Caches is not a bad feature, but it
> > should
> > > > be
> > > > > used
> > > > > > > > with
> > > > > > > > > > > > > caution.
> > > > > > > > > > > > > > > > > At least
we have to explain how it works on
> > > > > readme.io,
> > > > > > > > why and
> > > > > > > > > > > > > when
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > should
be used because usage can drop the
> > > > > performance
> > > > > > > > instead
> > > > > > > > > > > of
> > > > > > > > > > > > > > > > increasing
> > > > > > > > > > > > > > > > > it.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Anyway,
I added near caches because I never
> > > heard
> > > > > > > > someone used
> > > > > > > > > > > > them
> > > > > > > > > > > > > > > > > meaningfully,
not like a silver bullet.
> > > > > > > > > > > > > > > > > So, that's
just a proposal :)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Also,
I'd like to propose to have some
> voting
> > > > > about full
> > > > > > > > list
> > > > > > > > > > > > later
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > gain
> > > > > > > > > > > > > > > > > "must
be removed", "can be removed" and
> > "should
> > > > be
> > > > > kept"
> > > > > > > > lists.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Thu,
Jun 27, 2019 at 1:03 PM Alexey
> > > Goncharuk
> > > > <
> > > > > > > > > > > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
Anton,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
I would like to pull-up the discussion
> > > > regarding
> > > > > the
> > > > > > > > near
> > > > > > > > > > > > caches
> > > > > > > > > > > > > -
> > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > > cannot
> > > > > > > > > > > > > > > > > >
agree this is a feature that needs to be
> > > > > removed. Near
> > > > > > > > caches
> > > > > > > > > > > > > > provide
> > > > > > > > > > > > > > > > > >
significant read performance improvements
> > > and,
> > > > > to the
> > > > > > > > best of
> > > > > > > > > > > > my
> > > > > > > > > > > > > > > > > knowledge,
> > > > > > > > > > > > > > > > > >
are used in several cases in production.
> > Can
> > > > you
> > > > > > > > elaborate on
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >
shortcomings you faced? Maybe we can
> > improve
> > > > both
> > > > > > > > internal
> > > > > > > > > > > code
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > user
> > > > > > > > > > > > > > > > > >
experience?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
пт, 21 июн. 2019 г. в 10:42, Dmitry
> > > Melnichuk <
> > > > > > > > > > > > > > > > > >
dmitry.melnichuk@nobitlost.com>:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> Dmitry,
> > > > > > > > > > > > > > > > > >
> As a Python thin client developer, I
> > think
> > > > that
> > > > > > > > separate
> > > > > > > > > > > > > > repository
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > >
> a truly great idea!
> > > > > > > > > > > > > > > > > >
> On Tue, 2019-06-18 at 21:29 +0300,
> > Dmitriy
> > > > > Pavlov
> > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > - Move to separate repositories: thin
> > > > > clients (at
> > > > > > > > least
> > > > > > > > > > > > > > non-Java
> > > > > > > > > > > > > > > > > >
> >
> > > > > > > > > > > > > > > > > >
> > > ones)
> > > > > > > > > > > > > > > > > >
>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best regards,
> > > > > > > > > Ivan Pavlukhin
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > > Ivan Pavlukhin
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message