Hello!
I have checked that on master, and fallback to old behavior does not seem
to work for pre-existing clusters:
I am starting a cluster with two nodes with pre-existing PDS, and when I
start client, which would do setBaselineTopology, I get:
Caused by:
org.apache.ignite.internal.processors.cluster.BaselineAdjustForbiddenException:
Baseline auto-adjust is enabled, please turn-off it before try to adjust
baseline manually
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.changeGlobalState0
(GridClusterStateProcessor.java:996)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.changeGlobalState
(GridClusterStateProcessor.java:916)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.changeGlobalState
(GridClusterStateProcessor.java:895)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.changeGlobalState
(GridClusterStateProcessor.java:855)
at
org.apache.ignite.internal.cluster.IgniteClusterImpl.setBaselineTopology
(IgniteClusterImpl.java:387)
You can try that on a reproducer referenced in
https://issues.apache.org/jira/browse/IGNITE-12504 - start cluster in
2.6.0, run persistence-data-nodes/persistence, then upgrade (don't forget
H2) and start cluster again.
Regards,
--
Ilya Kasnacheev
пт, 27 дек. 2019 г. в 18:24, Anton Kalashnikov <kaa....@yandex.ru>:
> Hello.
>
> Ivan is right that "baseline auto-adjust" is disabled by default if you
> start your node on
> existing PDS. But "baseline auto-adjust" is enabled by default for
> in-memory cluster due to in-memory nodes also have bound to baseline since
> 2.8 version.
>
> Also, I want to note that after this ticket(
> https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-12227).
> "baseline auto-adjust" would be disabled by default for any persistent
> cluster(empty and existed one) because current logic is a little confused
> and can lead to some problems which described in the ticket.
>
> --
> Best regards,
> Anton Kalashnikov
>
>
> 27.12.2019, 17:58, "Ivan Bessonov" <bessonov...@gmail.com>:
> > Hello,
> >
> > "baseline auto-adjust" is disabled by default if you start your node on
> > existing PDS.
> > It's enabled on new clusters only.
> >
> > Existing installations should not be affected by the update. Is that ok?
> >
> > пт, 27 дек. 2019 г. в 14:46, Maxim Muzafarov <mmu...@apache.org>:
> >
> >> Ilya,
> >>
> >> +1 from my side.
> >>
> >> On Fri, 27 Dec 2019 at 14:36, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> >> wrote:
> >> >
> >> > Hello!
> >> >
> >> > I have also noticed that we have baseline auto-adjust enabled by
> default
> >> in
> >> > 2.8 builds, and it breaks existing code in runtime:
> >> > https://issues.apache.org/jira/browse/IGNITE-12504
> >> >
> >> > I propose to turn auto-adjust off by default in 2.8 release. What do
> you
> >> > think?
> >> >
> >> > Regards,
> >> > --
> >> > Ilya Kasnacheev
> >> >
> >> >
> >> > пт, 27 дек. 2019 г. в 12:40, Sergei Ryzhov <s.vi.ryz...@gmail.com>:
> >> >
> >> > > Hello!
> >> > > Task IGNITE-12470 is ready.
> >> > > https://issues.apache.org/jira/browse/IGNITE-12470
> >> > > Please check this API.
> >> > >
> >> > >
> >> > > Regards,
> >> > > Ryzhov Sergei.
> >> > >
> >> > > чт, 26 дек. 2019 г. в 18:50, Maxim Muzafarov <mmu...@apache.org>:
> >> > >
> >> > > > Ilya,
> >> > > >
> >> > > >
> >> > > > I agree with you that there is no risk and spring-data-2.2 can be
> >> > > > safely cherry-picked to the ignite-2.8 branch. I'm OK with it.
> Will
> >> > > > you do such merge or I should do it by myself?
> >> > > >
> >> > > >
> >> > > > As for the second part of your email, you are proposing to bump
> up a
> >> > > > minor dependencies version (no API changes) for the whole
> components
> >> > > > mentioned in the parent/pom.xml file, right? From a point of the
> >> > > > release view, it seems not a good thing since a scope test of the
> >> > > > release becomes too wider. I don't think we will simplify thus
> the
> >> > > > year-long release test scope, so as for me, this sounds not good
> but
> >> > > > I'd like to hear thoughts of other community members on this
> point.
> >> > > >
> >> > > > As an alternative, for instance, we can bump minor versions only
> for
> >> > > > those components which have security vulnerabilities. To find
> such
> >> > > > dependencies, I've run some local test with a maven
> >> > > > dependency-check-maven [1] an open-source dependency check tool.
> Here
> >> > > > is a brief report (only a few modules tested):
> >> > > >
> >> > > > spring-core-4.3.18.RELEASE.jar : CVE-2018-15756 [2]
> >> > > > h2-1.4.197.jar : CVE-2018-10054, CVE-2018-14335 (discussed also
> [3])
> >> > > > ignite-shmem-1.0.0.jar : CVE-2017-14614
> >> > > >
> >> > > >
> >> > > > [1] https://jeremylong.github.io/DependencyCheck/index.html
> >> > > > [2] https://nvd.nist.gov/vuln/detail/CVE-2018-15756
> >> > > > [3] https://issues.apache.org/jira/browse/IGNITE-10801
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Thu, 26 Dec 2019 at 15:52, Ilya Kasnacheev <
> >> ilya.kasnach...@gmail.com
> >> > > >
> >> > > > wrote:
> >> > > > >
> >> > > > > Hello!
> >> > > > >
> >> > > > > I propose to add the following ticket to the scope:
> >> > > > > https://issues.apache.org/jira/browse/IGNITE-12259 (3
> commits, be
> >> > > > careful
> >> > > > > with release version)
> >> > > > >
> >> > > > > Adding tickets to scope surely seems crazy now, but I will
> provide
> >> the
> >> > > > > following considerations:
> >> > > > > * This is Spring Data 2.2 integration, which we currently do
> not
> >> have,
> >> > > > > leading to lots of confused questions on stack overflow and
> mailing
> >> > > list.
> >> > > > > Spring Data is important to our public image since many people
> may
> >> > > learn
> >> > > > > about out project by starting with Spring Data.
> >> > > > >
> >> > > > > * It has zero code impact outside of its own module (just 2 POM
> >> file
> >> > > > > touched and that's all).
> >> > > > >
> >> > > > > * The core was ready since early November but, due to gmail
> quirk,
> >> we
> >> > > did
> >> > > > > not react to it in time.
> >> > > > >
> >> > > > > WDYT?
> >> > > > >
> >> > > > > Another semi-related question. *Should we bump our
> dependencies'
> >> > > versions
> >> > > > > before releasing 2.8?* I talk mainly about spring and hibernate
> >> > > > > dependencies. We could switch them to their latest maintenance
> >> versions
> >> > > > to
> >> > > > > avoid shipping default links to outdated packages.
> >> > > > >
> >> > > > > I think this is one of things that are very hard to do between
> >> > > releases,
> >> > > > so
> >> > > > > I think this dependencies bumping should be a part of a formal
> >> > > > > release/testing cycle, and then be backported to master.
> >> > > > >
> >> > > > > I could volunteer to do that myself, if we agree to merge these
> >> version
> >> > > > > upgrades to ignite-2.8 and then re-test.
> >> > > > >
> >> > > > > Regards,
> >> > > > > --
> >> > > > > Ilya Kasnacheev
> >> > > > >
> >> > > > >
> >> > > > > вт, 24 дек. 2019 г. в 13:22, Zhenya Stanilovsky
> >> > > > <arzamas...@mail.ru.invalid
> >> > > > > >:
> >> > > > >
> >> > > > > >
> >> > > > > > Igniters, i`l try to compare 2.8 release candidate vs 2.7.6,
> >> > > > > > last sha 2.8 was build from : 9d114f3137f92aebc2562a
> >> > > > > > i use yardstick benchmarks, 4 bare machine with: 2x Xeon
> X5570
> >> 96Gb
> >> > > > 512GB
> >> > > > > > SSD 2048GB HDD 10GB/s
> >> > > > > > 1 for client (driver) and 3 for servers.
> >> > > > > > this mappings for graphs and real yardstick tests:
> >> > > > > >
> >> > > > > > atomic-put: IgnitePutBenchmark
> >> > > > > > sql-merge-query: IgniteSqlMergeQueryBenchmark
> >> > > > > > atomic-get: IgniteGetBenchmark
> >> > > > > > tx-get: IgniteGetTxBenchmark
> >> > > > > > tx-put: IgnitePutTxBenchmark
> >> > > > > > atomic-put-all-bs-10: IgnitePutAllBenchmark
> >> > > > > > tx-put-all-bs-10: IgnitePutAllTxBenchmark
> >> > > > > >
> >> > > > > > cacheMode — partitioned
> >> > > > > > CacheWriteSynchronizationMode.FULL_SYNC
> >> > > > > > 1 backup
> >> > > > > >
> >> > > > > > 1. wal = log_only 2. wal = none 3. persistence disabled.
> >> > > > > > Thanks Maxim for wiki page [1]
> >> > > > > >
> >> > > > > >
> >> > > > > > [1]
> >> > > > > >
> >> > > >
> >> > >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Benchmarks
> >> > > > > >
> >> > > > > > do we need some bisect or other work here ?
> >> > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >------- Forwarded message -------
> >> > > > > > >From: "Maxim Muzafarov" < mmu...@apache.org >
> >> > > > > > >To: dev@ignite.apache.org
> >> > > > > > >Cc:
> >> > > > > > >Subject: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
> >> > > > > > >Date: Fri, 20 Sep 2019 14:44:31 +0300
> >> > > > > > >
> >> > > > > > >Igniters,
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >It's almost a year has passed since the last major Apache
> >> Ignite 2.7
> >> > > > > > >has been released. We've accumulated a lot of performance
> >> > > improvements
> >> > > > > > >and a lot of new features which are waiting for their
> release
> >> date.
> >> > > > > > >Here is my list of the most interesting things from my point
> >> since
> >> > > the
> >> > > > > > >last major release:
> >> > > > > > >
> >> > > > > > >Service Grid,
> >> > > > > > >Monitoring,
> >> > > > > > >Recovery Read
> >> > > > > > >BLT auto-adjust,
> >> > > > > > >PDS compression,
> >> > > > > > >WAL page compression,
> >> > > > > > >Thin client: best effort affinity,
> >> > > > > > >Thin client: transactions support (not yet)
> >> > > > > > >SQL query history
> >> > > > > > >SQL statistics
> >> > > > > > >
> >> > > > > > >I think we should no longer wait and freeze the master
> branch
> >> > > anymore
> >> > > > > > >and prepare the next major release by the end of the year.
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >I propose to discuss Time, Scope of Apache Ignite 2.8
> release
> >> and
> >> > > also
> >> > > > > > >I want to propose myself to be the release manager of the
> >> planning
> >> > > > > > >release.
> >> > > > > > >
> >> > > > > > >Scope Freeze: November 4, 2019
> >> > > > > > >Code Freeze: November 18, 2019
> >> > > > > > >Voting Date: December 10, 2019
> >> > > > > > >Release Date: December 17, 2019
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >WDYT?
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > >
> >> > >
> >
> > --
> > Sincerely yours,
> > Ivan Bessonov
>
