Postpone Apache Ignite 2.5 release to fix baseline topology

[Vladimir Ozerov]

Igniters, we have a problem.

Baseline topology was introduced in AI 2.4. Looks like it have two serious
flaws which confuse our users a lot:
1) No automatic rebalance by default
2) Topology misalignment between persistent and in-memory caches

These are really *critical* problems which severely affects virtually every
user. We agreed to return automatic re-balance by default and place
in-memory and persistent caches under the same umbrella.

I propose to postpone AI 2.5 until it is fixed. From what I heard it should
take about a month.

Please share your thoughts.

Vladimir.

[Dmitriy Pavlov]

Hi Vladimir,

The fact that we will postpone the release will somehow allow users to
receive fixes faster? What if we will fix (BL)AT it in 2.6 instead?

It will be additional issue for all developers to maintain 2.5 & master
branches.

Sincerely,
Dmitriy Pavlov

сб, 28 апр. 2018 г. в 17:28, Vladimir Ozerov <[hidden email]>:

> Igniters, we have a problem.
>
> Baseline topology was introduced in AI 2.4. Looks like it have two serious
> flaws which confuse our users a lot:
> 1) No automatic rebalance by default
> 2) Topology misalignment between persistent and in-memory caches
>
> These are really *critical* problems which severely affects virtually every
> user. We agreed to return automatic re-balance by default and place
> in-memory and persistent caches under the same umbrella.
>
> I propose to postpone AI 2.5 until it is fixed. From what I heard it should
> take about a month.
>
> Please share your thoughts.
>
> Vladimir.
>

[Dmitriy Pavlov]

-0.9 from me, because I want users get performance fix
https://issues.apache.org/jira/browse/IGNITE-7638 and 2 related fixes
faster.

сб, 28 апр. 2018 г. в 17:35, Dmitry Pavlov <[hidden email]>:

> Hi Vladimir,
>
> The fact that we will postpone the release will somehow allow users to
> receive fixes faster? What if we will fix (BL)AT it in 2.6 instead?
>
> It will be additional issue for all developers to maintain 2.5 & master
> branches.
>
> Sincerely,
> Dmitriy Pavlov
>
> сб, 28 апр. 2018 г. в 17:28, Vladimir Ozerov <[hidden email]>:
>
>> Igniters, we have a problem.
>>
>> Baseline topology was introduced in AI 2.4. Looks like it have two serious
>> flaws which confuse our users a lot:
>> 1) No automatic rebalance by default
>> 2) Topology misalignment between persistent and in-memory caches
>>
>> These are really *critical* problems which severely affects virtually
>> every
>> user. We agreed to return automatic re-balance by default and place
>> in-memory and persistent caches under the same umbrella.
>>
>> I propose to postpone AI 2.5 until it is fixed. From what I heard it
>> should
>> take about a month.
>>
>> Please share your thoughts.
>>
>> Vladimir.
>>
>

[Vladimir Ozerov]

Dmitry,

I think that developer convenience is of much smaller priority here than
user experience. Moreover, we are not going to unfreeze AI 2.5 scope
completely. Instead, we propose to add BLT fix to AI 2.5, but disallow
anything else. This way most contributors will continue working with master
as usual.

On Sat, Apr 28, 2018 at 5:36 PM, Dmitry Pavlov <[hidden email]>
wrote:

> Hi Vladimir,
>
> The fact that we will postpone the release will somehow allow users to
> receive fixes faster? What if we will fix (BL)AT it in 2.6 instead?
>
> It will be additional issue for all developers to maintain 2.5 & master
> branches.
>
> Sincerely,
> Dmitriy Pavlov
>
> сб, 28 апр. 2018 г. в 17:28, Vladimir Ozerov <[hidden email]>:
>
> > Igniters, we have a problem.
> >
> > Baseline topology was introduced in AI 2.4. Looks like it have two
> serious
> > flaws which confuse our users a lot:
> > 1) No automatic rebalance by default
> > 2) Topology misalignment between persistent and in-memory caches
> >
> > These are really *critical* problems which severely affects virtually
> every
> > user. We agreed to return automatic re-balance by default and place
> > in-memory and persistent caches under the same umbrella.
> >
> > I propose to postpone AI 2.5 until it is fixed. From what I heard it
> should
> > take about a month.
> >
> > Please share your thoughts.
> >
> > Vladimir.
> >
>

[Dmitriy Pavlov]

Ok, I understand process now. Thank you for clarification.

сб, 28 апр. 2018 г. в 17:41, Vladimir Ozerov <[hidden email]>:

> Dmitry,
>
> I think that developer convenience is of much smaller priority here than
> user experience. Moreover, we are not going to unfreeze AI 2.5 scope
> completely. Instead, we propose to add BLT fix to AI 2.5, but disallow
> anything else. This way most contributors will continue working with master
> as usual.
>
> On Sat, Apr 28, 2018 at 5:36 PM, Dmitry Pavlov <[hidden email]>
> wrote:
>
> > Hi Vladimir,
> >
> > The fact that we will postpone the release will somehow allow users to
> > receive fixes faster? What if we will fix (BL)AT it in 2.6 instead?
> >
> > It will be additional issue for all developers to maintain 2.5 & master
> > branches.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > сб, 28 апр. 2018 г. в 17:28, Vladimir Ozerov <[hidden email]>:
> >
> > > Igniters, we have a problem.
> > >
> > > Baseline topology was introduced in AI 2.4. Looks like it have two
> > serious
> > > flaws which confuse our users a lot:
> > > 1) No automatic rebalance by default
> > > 2) Topology misalignment between persistent and in-memory caches
> > >
> > > These are really *critical* problems which severely affects virtually
> > every
> > > user. We agreed to return automatic re-balance by default and place
> > > in-memory and persistent caches under the same umbrella.
> > >
> > > I propose to postpone AI 2.5 until it is fixed. From what I heard it
> > should
> > > take about a month.
> > >
> > > Please share your thoughts.
> > >
> > > Vladimir.
> > >
> >
>

[yzhdanov]

Guys, how about we release 2.5 in the nearest future after adding proper
usability log messages that will explain user what to do and also output
link to readme.io with the first BLT related message during node uptime.
This should not take much time and we can use the same messages when we
have (BL)AT modes in 2.6. I think that adding messages makes sense and
should be clear for users which is not the case for 2.4.

--Yakov

[Vladimir Ozerov]

Yakov,

Messages would help users understand what is wrong earlier, but will not
protect them from additional maintenance which is required in AI 2.4 and is
supposed to be removed in next AI releases.
Please note that in IEP-4 topic I proposed alternative solution - release
AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it would
be emergency release.

Both approaches works for me, the main goal is to deliver original defaults
ASAP. However, approach with a single release looks better to me because it
will minimize number of migrations for users.

Vladimir.


On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov <[hidden email]> wrote:

> Guys, how about we release 2.5 in the nearest future after adding proper
> usability log messages that will explain user what to do and also output
> link to readme.io with the first BLT related message during node uptime.
> This should not take much time and we can use the same messages when we
> have (BL)AT modes in 2.6. I think that adding messages makes sense and
> should be clear for users which is not the case for 2.4.
>
> --Yakov
>

[Dmitriy Pavlov]

I like AI 2.5 now, but then release AI 2.6 with (BL)AT fix. Probably we
will find some more changes to be delivered to users.

сб, 28 апр. 2018 г. в 17:56, Vladimir Ozerov <[hidden email]>:

> Yakov,
>
> Messages would help users understand what is wrong earlier, but will not
> protect them from additional maintenance which is required in AI 2.4 and is
> supposed to be removed in next AI releases.
> Please note that in IEP-4 topic I proposed alternative solution - release
> AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it would
> be emergency release.
>
> Both approaches works for me, the main goal is to deliver original defaults
> ASAP. However, approach with a single release looks better to me because it
> will minimize number of migrations for users.
>
> Vladimir.
>
>
> On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > Guys, how about we release 2.5 in the nearest future after adding proper
> > usability log messages that will explain user what to do and also output
> > link to readme.io with the first BLT related message during node uptime.
> > This should not take much time and we can use the same messages when we
> > have (BL)AT modes in 2.6. I think that adding messages makes sense and
> > should be clear for users which is not the case for 2.4.
> >
> > --Yakov
> >
>

[dmagda]

I'm backing up Vladimir's proposal to fix the behavior in 2.5 if it's not
time-consuming. To give you a bit more context on the subj, here is why we
should have the fix to be delivered in 2.5:
http://apache-ignite-users.70518.x6.nabble.com/Problems-
with-persistence-and-partitioned-cache-in-2-4-0-td21325.html

Frankly, it's not the first time I see similar complaints from those who
are on 2.4.

Alex G., Vovan, how hard is it to fix this?

--
Denis


On Sat, Apr 28, 2018 at 7:56 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Yakov,
>
> Messages would help users understand what is wrong earlier, but will not
> protect them from additional maintenance which is required in AI 2.4 and is
> supposed to be removed in next AI releases.
> Please note that in IEP-4 topic I proposed alternative solution - release
> AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it would
> be emergency release.
>
> Both approaches works for me, the main goal is to deliver original defaults
> ASAP. However, approach with a single release looks better to me because it
> will minimize number of migrations for users.
>
> Vladimir.
>
>
> On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > Guys, how about we release 2.5 in the nearest future after adding proper
> > usability log messages that will explain user what to do and also output
> > link to readme.io with the first BLT related message during node uptime.
> > This should not take much time and we can use the same messages when we
> > have (BL)AT modes in 2.6. I think that adding messages makes sense and
> > should be clear for users which is not the case for 2.4.
> >
> > --Yakov
> >
>

[dsetrakyan]

Can someone explain what is the before and after effect for this change
from the usability standpoint. If we are changing BLT for the in-memory
mode, which is the default, then we must think through all the usability
consequences ahead of time. Otherwise, the perception will be that the
product stopped working because someone did not know to activate the
cluster.

D.

On Sat, Apr 28, 2018 at 9:27 AM, Denis Magda <[hidden email]> wrote:

> I'm backing up Vladimir's proposal to fix the behavior in 2.5 if it's not
> time-consuming. To give you a bit more context on the subj, here is why we
> should have the fix to be delivered in 2.5:
> http://apache-ignite-users.70518.x6.nabble.com/Problems-
> with-persistence-and-partitioned-cache-in-2-4-0-td21325.html
>
> Frankly, it's not the first time I see similar complaints from those who
> are on 2.4.
>
> Alex G., Vovan, how hard is it to fix this?
>
> --
> Denis
>
>
> On Sat, Apr 28, 2018 at 7:56 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Yakov,
> >
> > Messages would help users understand what is wrong earlier, but will not
> > protect them from additional maintenance which is required in AI 2.4 and
> is
> > supposed to be removed in next AI releases.
> > Please note that in IEP-4 topic I proposed alternative solution - release
> > AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it
> would
> > be emergency release.
> >
> > Both approaches works for me, the main goal is to deliver original
> defaults
> > ASAP. However, approach with a single release looks better to me because
> it
> > will minimize number of migrations for users.
> >
> > Vladimir.
> >
> >
> > On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov <[hidden email]>
> > wrote:
> >
> > > Guys, how about we release 2.5 in the nearest future after adding
> proper
> > > usability log messages that will explain user what to do and also
> output
> > > link to readme.io with the first BLT related message during node
> uptime.
> > > This should not take much time and we can use the same messages when we
> > > have (BL)AT modes in 2.6. I think that adding messages makes sense and
> > > should be clear for users which is not the case for 2.4.
> > >
> > > --Yakov
> > >
> >
>

[Dmitriy Pavlov]

Hi Dmitriy,

As far as I understand manual activation will not be required for in-memory
mode (same for persistence). Change means we will change node state from
'joined-inactive' to 'joined-active' according to that user defined in
policy (cluster grow policy).

Default will be allow to rebalance data to joined node, probably, with some
delay. This detail will be defenetely discussed at dev list before
implementation.

Pros: Persistent users will not be facing with disabled rebalancing in case
of node left - (BL)AT will be changed automatically. This also be handled
by cluster shrink policy for both in-memory and durable cases.

Sincerely,
Dmitriy Pavlov

сб, 28 апр. 2018 г. в 21:10, Dmitriy Setrakyan <[hidden email]>:

> Can someone explain what is the before and after effect for this change
> from the usability standpoint. If we are changing BLT for the in-memory
> mode, which is the default, then we must think through all the usability
> consequences ahead of time. Otherwise, the perception will be that the
> product stopped working because someone did not know to activate the
> cluster.
>
> D.
>
> On Sat, Apr 28, 2018 at 9:27 AM, Denis Magda <[hidden email]> wrote:
>
> > I'm backing up Vladimir's proposal to fix the behavior in 2.5 if it's not
> > time-consuming. To give you a bit more context on the subj, here is why
> we
> > should have the fix to be delivered in 2.5:
> > http://apache-ignite-users.70518.x6.nabble.com/Problems-
> > with-persistence-and-partitioned-cache-in-2-4-0-td21325.html
> >
> > Frankly, it's not the first time I see similar complaints from those who
> > are on 2.4.
> >
> > Alex G., Vovan, how hard is it to fix this?
> >
> > --
> > Denis
> >
> >
> > On Sat, Apr 28, 2018 at 7:56 AM, Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > Yakov,
> > >
> > > Messages would help users understand what is wrong earlier, but will
> not
> > > protect them from additional maintenance which is required in AI 2.4
> and
> > is
> > > supposed to be removed in next AI releases.
> > > Please note that in IEP-4 topic I proposed alternative solution -
> release
> > > AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it
> > would
> > > be emergency release.
> > >
> > > Both approaches works for me, the main goal is to deliver original
> > defaults
> > > ASAP. However, approach with a single release looks better to me
> because
> > it
> > > will minimize number of migrations for users.
> > >
> > > Vladimir.
> > >
> > >
> > > On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov <[hidden email]>
> > > wrote:
> > >
> > > > Guys, how about we release 2.5 in the nearest future after adding
> > proper
> > > > usability log messages that will explain user what to do and also
> > output
> > > > link to readme.io with the first BLT related message during node
> > uptime.
> > > > This should not take much time and we can use the same messages when
> we
> > > > have (BL)AT modes in 2.6. I think that adding messages makes sense
> and
> > > > should be clear for users which is not the case for 2.4.
> > > >
> > > > --Yakov
> > > >
> > >
> >
>

[agura]

Igniters,

I believe BLT is serious usability problem but rush isn't good idea
because can lead to new bugs. As release manager I think that we
should move BLT fix to Apache Ignite 2.6 release and focus on issues
included to the AI 2.5 release scope.
I also want inform you that code freeze is planned for Friday, May 11.

Thanks!

On Sun, Apr 29, 2018 at 8:44 PM, Dmitry Pavlov <[hidden email]> wrote:

> Hi Dmitriy,
>
> As far as I understand manual activation will not be required for in-memory
> mode (same for persistence). Change means we will change node state from
> 'joined-inactive' to 'joined-active' according to that user defined in
> policy (cluster grow policy).
>
> Default will be allow to rebalance data to joined node, probably, with some
> delay. This detail will be defenetely discussed at dev list before
> implementation.
>
> Pros: Persistent users will not be facing with disabled rebalancing in case
> of node left - (BL)AT will be changed automatically. This also be handled
> by cluster shrink policy for both in-memory and durable cases.
>
> Sincerely,
> Dmitriy Pavlov
>
> сб, 28 апр. 2018 г. в 21:10, Dmitriy Setrakyan <[hidden email]>:
>
>> Can someone explain what is the before and after effect for this change
>> from the usability standpoint. If we are changing BLT for the in-memory
>> mode, which is the default, then we must think through all the usability
>> consequences ahead of time. Otherwise, the perception will be that the
>> product stopped working because someone did not know to activate the
>> cluster.
>>
>> D.
>>
>> On Sat, Apr 28, 2018 at 9:27 AM, Denis Magda <[hidden email]> wrote:
>>
>> > I'm backing up Vladimir's proposal to fix the behavior in 2.5 if it's not
>> > time-consuming. To give you a bit more context on the subj, here is why
>> we
>> > should have the fix to be delivered in 2.5:
>> > http://apache-ignite-users.70518.x6.nabble.com/Problems-
>> > with-persistence-and-partitioned-cache-in-2-4-0-td21325.html
>> >
>> > Frankly, it's not the first time I see similar complaints from those who
>> > are on 2.4.
>> >
>> > Alex G., Vovan, how hard is it to fix this?
>> >
>> > --
>> > Denis
>> >
>> >
>> > On Sat, Apr 28, 2018 at 7:56 AM, Vladimir Ozerov <[hidden email]>
>> > wrote:
>> >
>> > > Yakov,
>> > >
>> > > Messages would help users understand what is wrong earlier, but will
>> not
>> > > protect them from additional maintenance which is required in AI 2.4
>> and
>> > is
>> > > supposed to be removed in next AI releases.
>> > > Please note that in IEP-4 topic I proposed alternative solution -
>> release
>> > > AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it
>> > would
>> > > be emergency release.
>> > >
>> > > Both approaches works for me, the main goal is to deliver original
>> > defaults
>> > > ASAP. However, approach with a single release looks better to me
>> because
>> > it
>> > > will minimize number of migrations for users.
>> > >
>> > > Vladimir.
>> > >
>> > >
>> > > On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov <[hidden email]>
>> > > wrote:
>> > >
>> > > > Guys, how about we release 2.5 in the nearest future after adding
>> > proper
>> > > > usability log messages that will explain user what to do and also
>> > output
>> > > > link to readme.io with the first BLT related message during node
>> > uptime.
>> > > > This should not take much time and we can use the same messages when
>> we
>> > > > have (BL)AT modes in 2.6. I think that adding messages makes sense
>> and
>> > > > should be clear for users which is not the case for 2.4.
>> > > >
>> > > > --Yakov
>> > > >
>> > >
>> >
>>

[dsetrakyan]

Completely support the decision to move any BLT behavior changes to 2.6.
However, in 2.5 we need to add usability log messages, which I believe we
already have.

D.

On Tue, May 8, 2018 at 2:15 PM, Andrey Gura <[hidden email]> wrote:

> Igniters,
>
> I believe BLT is serious usability problem but rush isn't good idea
> because can lead to new bugs. As release manager I think that we
> should move BLT fix to Apache Ignite 2.6 release and focus on issues
> included to the AI 2.5 release scope.
> I also want inform you that code freeze is planned for Friday, May 11.
>
> Thanks!
>
> On Sun, Apr 29, 2018 at 8:44 PM, Dmitry Pavlov <[hidden email]>
> wrote:
> > Hi Dmitriy,
> >
> > As far as I understand manual activation will not be required for
> in-memory
> > mode (same for persistence). Change means we will change node state from
> > 'joined-inactive' to 'joined-active' according to that user defined in
> > policy (cluster grow policy).
> >
> > Default will be allow to rebalance data to joined node, probably, with
> some
> > delay. This detail will be defenetely discussed at dev list before
> > implementation.
> >
> > Pros: Persistent users will not be facing with disabled rebalancing in
> case
> > of node left - (BL)AT will be changed automatically. This also be handled
> > by cluster shrink policy for both in-memory and durable cases.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > сб, 28 апр. 2018 г. в 21:10, Dmitriy Setrakyan <[hidden email]>:
> >
> >> Can someone explain what is the before and after effect for this change
> >> from the usability standpoint. If we are changing BLT for the in-memory
> >> mode, which is the default, then we must think through all the usability
> >> consequences ahead of time. Otherwise, the perception will be that the
> >> product stopped working because someone did not know to activate the
> >> cluster.
> >>
> >> D.
> >>
> >> On Sat, Apr 28, 2018 at 9:27 AM, Denis Magda <[hidden email]> wrote:
> >>
> >> > I'm backing up Vladimir's proposal to fix the behavior in 2.5 if it's
> not
> >> > time-consuming. To give you a bit more context on the subj, here is
> why
> >> we
> >> > should have the fix to be delivered in 2.5:
> >> > http://apache-ignite-users.70518.x6.nabble.com/Problems-
> >> > with-persistence-and-partitioned-cache-in-2-4-0-td21325.html
> >> >
> >> > Frankly, it's not the first time I see similar complaints from those
> who
> >> > are on 2.4.
> >> >
> >> > Alex G., Vovan, how hard is it to fix this?
> >> >
> >> > --
> >> > Denis
> >> >
> >> >
> >> > On Sat, Apr 28, 2018 at 7:56 AM, Vladimir Ozerov <
> [hidden email]>
> >> > wrote:
> >> >
> >> > > Yakov,
> >> > >
> >> > > Messages would help users understand what is wrong earlier, but will
> >> not
> >> > > protect them from additional maintenance which is required in AI 2.4
> >> and
> >> > is
> >> > > supposed to be removed in next AI releases.
> >> > > Please note that in IEP-4 topic I proposed alternative solution -
> >> release
> >> > > AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it
> >> > would
> >> > > be emergency release.
> >> > >
> >> > > Both approaches works for me, the main goal is to deliver original
> >> > defaults
> >> > > ASAP. However, approach with a single release looks better to me
> >> because
> >> > it
> >> > > will minimize number of migrations for users.
> >> > >
> >> > > Vladimir.
> >> > >
> >> > >
> >> > > On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov <[hidden email]
> >
> >> > > wrote:
> >> > >
> >> > > > Guys, how about we release 2.5 in the nearest future after adding
> >> > proper
> >> > > > usability log messages that will explain user what to do and also
> >> > output
> >> > > > link to readme.io with the first BLT related message during node
> >> > uptime.
> >> > > > This should not take much time and we can use the same messages
> when
> >> we
> >> > > > have (BL)AT modes in 2.6. I think that adding messages makes sense
> >> and
> >> > > > should be clear for users which is not the case for 2.4.
> >> > > >
> >> > > > --Yakov
> >> > > >
> >> > >
> >> >
> >>
>

[agura]

Dmitry,

additional BLT related logging is already added. I hope it will help
users to understand BLT better.

On Tue, May 8, 2018 at 3:36 PM, Dmitriy Setrakyan <[hidden email]> wrote:

> Completely support the decision to move any BLT behavior changes to 2.6.
> However, in 2.5 we need to add usability log messages, which I believe we
> already have.
>
> D.
>
> On Tue, May 8, 2018 at 2:15 PM, Andrey Gura <[hidden email]> wrote:
>
>> Igniters,
>>
>> I believe BLT is serious usability problem but rush isn't good idea
>> because can lead to new bugs. As release manager I think that we
>> should move BLT fix to Apache Ignite 2.6 release and focus on issues
>> included to the AI 2.5 release scope.
>> I also want inform you that code freeze is planned for Friday, May 11.
>>
>> Thanks!
>>
>> On Sun, Apr 29, 2018 at 8:44 PM, Dmitry Pavlov <[hidden email]>
>> wrote:
>> > Hi Dmitriy,
>> >
>> > As far as I understand manual activation will not be required for
>> in-memory
>> > mode (same for persistence). Change means we will change node state from
>> > 'joined-inactive' to 'joined-active' according to that user defined in
>> > policy (cluster grow policy).
>> >
>> > Default will be allow to rebalance data to joined node, probably, with
>> some
>> > delay. This detail will be defenetely discussed at dev list before
>> > implementation.
>> >
>> > Pros: Persistent users will not be facing with disabled rebalancing in
>> case
>> > of node left - (BL)AT will be changed automatically. This also be handled
>> > by cluster shrink policy for both in-memory and durable cases.
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> > сб, 28 апр. 2018 г. в 21:10, Dmitriy Setrakyan <[hidden email]>:
>> >
>> >> Can someone explain what is the before and after effect for this change
>> >> from the usability standpoint. If we are changing BLT for the in-memory
>> >> mode, which is the default, then we must think through all the usability
>> >> consequences ahead of time. Otherwise, the perception will be that the
>> >> product stopped working because someone did not know to activate the
>> >> cluster.
>> >>
>> >> D.
>> >>
>> >> On Sat, Apr 28, 2018 at 9:27 AM, Denis Magda <[hidden email]> wrote:
>> >>
>> >> > I'm backing up Vladimir's proposal to fix the behavior in 2.5 if it's
>> not
>> >> > time-consuming. To give you a bit more context on the subj, here is
>> why
>> >> we
>> >> > should have the fix to be delivered in 2.5:
>> >> > http://apache-ignite-users.70518.x6.nabble.com/Problems-
>> >> > with-persistence-and-partitioned-cache-in-2-4-0-td21325.html
>> >> >
>> >> > Frankly, it's not the first time I see similar complaints from those
>> who
>> >> > are on 2.4.
>> >> >
>> >> > Alex G., Vovan, how hard is it to fix this?
>> >> >
>> >> > --
>> >> > Denis
>> >> >
>> >> >
>> >> > On Sat, Apr 28, 2018 at 7:56 AM, Vladimir Ozerov <
>> [hidden email]>
>> >> > wrote:
>> >> >
>> >> > > Yakov,
>> >> > >
>> >> > > Messages would help users understand what is wrong earlier, but will
>> >> not
>> >> > > protect them from additional maintenance which is required in AI 2.4
>> >> and
>> >> > is
>> >> > > supposed to be removed in next AI releases.
>> >> > > Please note that in IEP-4 topic I proposed alternative solution -
>> >> release
>> >> > > AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it
>> >> > would
>> >> > > be emergency release.
>> >> > >
>> >> > > Both approaches works for me, the main goal is to deliver original
>> >> > defaults
>> >> > > ASAP. However, approach with a single release looks better to me
>> >> because
>> >> > it
>> >> > > will minimize number of migrations for users.
>> >> > >
>> >> > > Vladimir.
>> >> > >
>> >> > >
>> >> > > On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov <[hidden email]
>> >
>> >> > > wrote:
>> >> > >
>> >> > > > Guys, how about we release 2.5 in the nearest future after adding
>> >> > proper
>> >> > > > usability log messages that will explain user what to do and also
>> >> > output
>> >> > > > link to readme.io with the first BLT related message during node
>> >> > uptime.
>> >> > > > This should not take much time and we can use the same messages
>> when
>> >> we
>> >> > > > have (BL)AT modes in 2.6. I think that adding messages makes sense
>> >> and
>> >> > > > should be clear for users which is not the case for 2.4.
>> >> > > >
>> >> > > > --Yakov
>> >> > > >
>> >> > >
>> >> >
>> >>
>>