[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false
[ https://issues.apache.org/jira/browse/SOLR-11503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383964#comment-16383964 ] ASF subversion and git services commented on SOLR-11503: Commit d1e9bbd333ea55cfa0c75d324424606e857a775b in lucene-solr's branch refs/heads/branch_6_6 from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d1e9bbd ] SOLR-11503: In ZkController.waitForCoreNodeName(), persist core.properties after setting the coreNodeName > Collections created with legacyCloud=true cannot be opened if > legacyCloud=false > --- > > Key: SOLR-11503 > URL: https://issues.apache.org/jira/browse/SOLR-11503 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Critical > Fix For: 7.2, master (8.0), 6.6.3 > > Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, > SOLR-11503.patch > > > SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a > collection with legacyCloud=true then switch to legacyCloud=false, you get an > NPE because coreNodeName is not defined in core.properties. > Since the default for legacyCloud changed from true to false between 6.6.1 > and 7.x, this means that any attempt to upgrade Solr with existing > collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value > for legacyCloud is used in both. Collections created with 6.6.0 would work. > Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work. > This is not as egregious with any collections *created with 7.0* since if the > default legacyCloud=false is present when the core is created, properties are > persisted with coreNodeName. However, if someone switches legacyCloud to > true, then creates a collection, then changes legacyCloud back to false then > they'll hit this even in 7.0+ > This happened because bit of reordering switched the order of the calls > below. coreNodeName is added to the descriptor in > create/createFromDescriptor(this, cd) via zkContgroller.preRegister so > coresLocator.create(this, cd) persists core.properties without coreNodeName. > _original order_ > SolrCore core = createFromDescriptor(cd, true, newCollection); > coresLocator.create(this, cd); > (NOTE: private calls to create were renamed to createFromDescriptor in > SOLR-11122). > I've got a fix in the works for creating cores, I'll attach a preliminary > patch w/o tests in a bit for discussion, but the question is really what to > do about 6.6.1 and 6.6.2 and 7.1 for that matter. > This is compounded by the fact that with the CVE, there's strong incentive to > move to 6.6.2. sgh. > There are two parts to fixing this completely: > 1> create core.properties correctly > 2> deal with coreNodeName not being in the core.properties file by going to > ZK and getting it (and persisting it). Haven't worked that part out yet > though, not in the first patch. Note one point here if it works as I hope it > will update the core.properties files first time they're opened. > Options that I see, there are really two parts: > *part1 create the core.properties correctly* > > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem. > > Recommend people not install 7x over collections created with 6x until they > > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and > > creating collections is at your own risk. > > Recommend that people change legacyCloud=true in 7.x until they start > > working with a fixed version, which one TBD. > *part2 deal with coreNodeName not being in the core.properties* > > Not backport and release with 7.2? set legacyCloud=true until then. > > Backport to point releases like 7.1.1? 6.6.3? > > and what about 7.0? I don't think many people will be affected by 7.0 since > > 7.1 came out so soon after. And setting legacyCloud=true will let people > > get by. > Fixing the two parts is not a question, they both need to be fixed. The real > question is whether we need to create a point release that incorporates one > or both or whether saying "you must set legacyCloud=true prior to Solr > version 7.# in order to work with any collections created with Solr versions > 6.6.1 through 7.#". > Let's hear opinions.. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false
[ https://issues.apache.org/jira/browse/SOLR-11503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383790#comment-16383790 ] ASF subversion and git services commented on SOLR-11503: Commit 2d0c3e1f9b5c03f024b9d3b1d86eac8b85dc7fe4 in lucene-solr's branch refs/heads/branch_6_6 from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2d0c3e1 ] SOLR-11503: remove 'replicaType' from required properties list in LegacyCloudClusterPropTest (not applicable prior to Solr 7.0) > Collections created with legacyCloud=true cannot be opened if > legacyCloud=false > --- > > Key: SOLR-11503 > URL: https://issues.apache.org/jira/browse/SOLR-11503 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Critical > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, > SOLR-11503.patch > > > SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a > collection with legacyCloud=true then switch to legacyCloud=false, you get an > NPE because coreNodeName is not defined in core.properties. > Since the default for legacyCloud changed from true to false between 6.6.1 > and 7.x, this means that any attempt to upgrade Solr with existing > collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value > for legacyCloud is used in both. Collections created with 6.6.0 would work. > Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work. > This is not as egregious with any collections *created with 7.0* since if the > default legacyCloud=false is present when the core is created, properties are > persisted with coreNodeName. However, if someone switches legacyCloud to > true, then creates a collection, then changes legacyCloud back to false then > they'll hit this even in 7.0+ > This happened because bit of reordering switched the order of the calls > below. coreNodeName is added to the descriptor in > create/createFromDescriptor(this, cd) via zkContgroller.preRegister so > coresLocator.create(this, cd) persists core.properties without coreNodeName. > _original order_ > SolrCore core = createFromDescriptor(cd, true, newCollection); > coresLocator.create(this, cd); > (NOTE: private calls to create were renamed to createFromDescriptor in > SOLR-11122). > I've got a fix in the works for creating cores, I'll attach a preliminary > patch w/o tests in a bit for discussion, but the question is really what to > do about 6.6.1 and 6.6.2 and 7.1 for that matter. > This is compounded by the fact that with the CVE, there's strong incentive to > move to 6.6.2. sgh. > There are two parts to fixing this completely: > 1> create core.properties correctly > 2> deal with coreNodeName not being in the core.properties file by going to > ZK and getting it (and persisting it). Haven't worked that part out yet > though, not in the first patch. Note one point here if it works as I hope it > will update the core.properties files first time they're opened. > Options that I see, there are really two parts: > *part1 create the core.properties correctly* > > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem. > > Recommend people not install 7x over collections created with 6x until they > > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and > > creating collections is at your own risk. > > Recommend that people change legacyCloud=true in 7.x until they start > > working with a fixed version, which one TBD. > *part2 deal with coreNodeName not being in the core.properties* > > Not backport and release with 7.2? set legacyCloud=true until then. > > Backport to point releases like 7.1.1? 6.6.3? > > and what about 7.0? I don't think many people will be affected by 7.0 since > > 7.1 came out so soon after. And setting legacyCloud=true will let people > > get by. > Fixing the two parts is not a question, they both need to be fixed. The real > question is whether we need to create a point release that incorporates one > or both or whether saying "you must set legacyCloud=true prior to Solr > version 7.# in order to work with any collections created with Solr versions > 6.6.1 through 7.#". > Let's hear opinions.. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false
[
https://issues.apache.org/jira/browse/SOLR-11503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383061#comment-16383061
]
Steve Rowe commented on SOLR-11503:
---
On the branch_6_6 backport I fixed a missing import in CoreContainer.java.
There is a reproducing failure a local test run turned up:
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=LegacyCloudClusterPropTest
-Dtests.method=testCreateCollectionSwitchLegacyCloud
-Dtests.seed=3E3D3F067ED986BE -Dtests.slow=true -Dtests.locale=zh-SG
-Dtests.timezone=America/Rio_Branco -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] FAILURE 3.60s |
LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud <<<
[junit4]> Throwable #1: java.lang.AssertionError: Should have found
property replicaType in properties file
[junit4]>at
__randomizedtesting.SeedInfo.seed([3E3D3F067ED986BE:EF3ACD83DAD60D8C]:0)
[junit4]>at
org.apache.solr.cloud.LegacyCloudClusterPropTest.checkMandatoryProps(LegacyCloudClusterPropTest.java:158)
[junit4]>at
org.apache.solr.cloud.LegacyCloudClusterPropTest.createAndTest(LegacyCloudClusterPropTest.java:90)
[junit4]>at
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud(LegacyCloudClusterPropTest.java:69)
[junit4]>at java.lang.Thread.run(Thread.java:748)
{noformat}
[~erickerickson], does this ring a bell?
> Collections created with legacyCloud=true cannot be opened if
> legacyCloud=false
> ---
>
> Key: SOLR-11503
> URL: https://issues.apache.org/jira/browse/SOLR-11503
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6.1
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Critical
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch,
> SOLR-11503.patch
>
>
> SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a
> collection with legacyCloud=true then switch to legacyCloud=false, you get an
> NPE because coreNodeName is not defined in core.properties.
> Since the default for legacyCloud changed from true to false between 6.6.1
> and 7.x, this means that any attempt to upgrade Solr with existing
> collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value
> for legacyCloud is used in both. Collections created with 6.6.0 would work.
> Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work.
> This is not as egregious with any collections *created with 7.0* since if the
> default legacyCloud=false is present when the core is created, properties are
> persisted with coreNodeName. However, if someone switches legacyCloud to
> true, then creates a collection, then changes legacyCloud back to false then
> they'll hit this even in 7.0+
> This happened because bit of reordering switched the order of the calls
> below. coreNodeName is added to the descriptor in
> create/createFromDescriptor(this, cd) via zkContgroller.preRegister so
> coresLocator.create(this, cd) persists core.properties without coreNodeName.
> _original order_
> SolrCore core = createFromDescriptor(cd, true, newCollection);
> coresLocator.create(this, cd);
> (NOTE: private calls to create were renamed to createFromDescriptor in
> SOLR-11122).
> I've got a fix in the works for creating cores, I'll attach a preliminary
> patch w/o tests in a bit for discussion, but the question is really what to
> do about 6.6.1 and 6.6.2 and 7.1 for that matter.
> This is compounded by the fact that with the CVE, there's strong incentive to
> move to 6.6.2. sgh.
> There are two parts to fixing this completely:
> 1> create core.properties correctly
> 2> deal with coreNodeName not being in the core.properties file by going to
> ZK and getting it (and persisting it). Haven't worked that part out yet
> though, not in the first patch. Note one point here if it works as I hope it
> will update the core.properties files first time they're opened.
> Options that I see, there are really two parts:
> *part1 create the core.properties correctly*
> > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem.
> > Recommend people not install 7x over collections created with 6x until they
> > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and
> > creating collections is at your own risk.
> > Recommend that people change legacyCloud=true in 7.x until they start
> > working with a fixed version, which one TBD.
> *part2 deal with coreNodeName not being in the core.properties*
> > Not backport and release with 7.2? set legacyCloud
[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false
[ https://issues.apache.org/jira/browse/SOLR-11503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383053#comment-16383053 ] ASF subversion and git services commented on SOLR-11503: Commit bad96329a39855ebc5ecbcea5897c53ece18f46b in lucene-solr's branch refs/heads/branch_6_6 from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bad9632 ] SOLR-11503: add missing import > Collections created with legacyCloud=true cannot be opened if > legacyCloud=false > --- > > Key: SOLR-11503 > URL: https://issues.apache.org/jira/browse/SOLR-11503 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Critical > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, > SOLR-11503.patch > > > SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a > collection with legacyCloud=true then switch to legacyCloud=false, you get an > NPE because coreNodeName is not defined in core.properties. > Since the default for legacyCloud changed from true to false between 6.6.1 > and 7.x, this means that any attempt to upgrade Solr with existing > collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value > for legacyCloud is used in both. Collections created with 6.6.0 would work. > Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work. > This is not as egregious with any collections *created with 7.0* since if the > default legacyCloud=false is present when the core is created, properties are > persisted with coreNodeName. However, if someone switches legacyCloud to > true, then creates a collection, then changes legacyCloud back to false then > they'll hit this even in 7.0+ > This happened because bit of reordering switched the order of the calls > below. coreNodeName is added to the descriptor in > create/createFromDescriptor(this, cd) via zkContgroller.preRegister so > coresLocator.create(this, cd) persists core.properties without coreNodeName. > _original order_ > SolrCore core = createFromDescriptor(cd, true, newCollection); > coresLocator.create(this, cd); > (NOTE: private calls to create were renamed to createFromDescriptor in > SOLR-11122). > I've got a fix in the works for creating cores, I'll attach a preliminary > patch w/o tests in a bit for discussion, but the question is really what to > do about 6.6.1 and 6.6.2 and 7.1 for that matter. > This is compounded by the fact that with the CVE, there's strong incentive to > move to 6.6.2. sgh. > There are two parts to fixing this completely: > 1> create core.properties correctly > 2> deal with coreNodeName not being in the core.properties file by going to > ZK and getting it (and persisting it). Haven't worked that part out yet > though, not in the first patch. Note one point here if it works as I hope it > will update the core.properties files first time they're opened. > Options that I see, there are really two parts: > *part1 create the core.properties correctly* > > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem. > > Recommend people not install 7x over collections created with 6x until they > > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and > > creating collections is at your own risk. > > Recommend that people change legacyCloud=true in 7.x until they start > > working with a fixed version, which one TBD. > *part2 deal with coreNodeName not being in the core.properties* > > Not backport and release with 7.2? set legacyCloud=true until then. > > Backport to point releases like 7.1.1? 6.6.3? > > and what about 7.0? I don't think many people will be affected by 7.0 since > > 7.1 came out so soon after. And setting legacyCloud=true will let people > > get by. > Fixing the two parts is not a question, they both need to be fixed. The real > question is whether we need to create a point release that incorporates one > or both or whether saying "you must set legacyCloud=true prior to Solr > version 7.# in order to work with any collections created with Solr versions > 6.6.1 through 7.#". > Let's hear opinions.. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false
[ https://issues.apache.org/jira/browse/SOLR-11503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382723#comment-16382723 ] ASF subversion and git services commented on SOLR-11503: Commit b4e33a038569f97752abd61a26e8af0b652e5b44 in lucene-solr's branch refs/heads/branch_6_6 from Erick Erickson [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b4e33a0 ] SOLR-11503: Collections created with legacyCloud=true cannot be opened if legacyCloud=false > Collections created with legacyCloud=true cannot be opened if > legacyCloud=false > --- > > Key: SOLR-11503 > URL: https://issues.apache.org/jira/browse/SOLR-11503 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Critical > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, > SOLR-11503.patch > > > SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a > collection with legacyCloud=true then switch to legacyCloud=false, you get an > NPE because coreNodeName is not defined in core.properties. > Since the default for legacyCloud changed from true to false between 6.6.1 > and 7.x, this means that any attempt to upgrade Solr with existing > collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value > for legacyCloud is used in both. Collections created with 6.6.0 would work. > Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work. > This is not as egregious with any collections *created with 7.0* since if the > default legacyCloud=false is present when the core is created, properties are > persisted with coreNodeName. However, if someone switches legacyCloud to > true, then creates a collection, then changes legacyCloud back to false then > they'll hit this even in 7.0+ > This happened because bit of reordering switched the order of the calls > below. coreNodeName is added to the descriptor in > create/createFromDescriptor(this, cd) via zkContgroller.preRegister so > coresLocator.create(this, cd) persists core.properties without coreNodeName. > _original order_ > SolrCore core = createFromDescriptor(cd, true, newCollection); > coresLocator.create(this, cd); > (NOTE: private calls to create were renamed to createFromDescriptor in > SOLR-11122). > I've got a fix in the works for creating cores, I'll attach a preliminary > patch w/o tests in a bit for discussion, but the question is really what to > do about 6.6.1 and 6.6.2 and 7.1 for that matter. > This is compounded by the fact that with the CVE, there's strong incentive to > move to 6.6.2. sgh. > There are two parts to fixing this completely: > 1> create core.properties correctly > 2> deal with coreNodeName not being in the core.properties file by going to > ZK and getting it (and persisting it). Haven't worked that part out yet > though, not in the first patch. Note one point here if it works as I hope it > will update the core.properties files first time they're opened. > Options that I see, there are really two parts: > *part1 create the core.properties correctly* > > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem. > > Recommend people not install 7x over collections created with 6x until they > > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and > > creating collections is at your own risk. > > Recommend that people change legacyCloud=true in 7.x until they start > > working with a fixed version, which one TBD. > *part2 deal with coreNodeName not being in the core.properties* > > Not backport and release with 7.2? set legacyCloud=true until then. > > Backport to point releases like 7.1.1? 6.6.3? > > and what about 7.0? I don't think many people will be affected by 7.0 since > > 7.1 came out so soon after. And setting legacyCloud=true will let people > > get by. > Fixing the two parts is not a question, they both need to be fixed. The real > question is whether we need to create a point release that incorporates one > or both or whether saying "you must set legacyCloud=true prior to Solr > version 7.# in order to work with any collections created with Solr versions > 6.6.1 through 7.#". > Let's hear opinions.. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false
[ https://issues.apache.org/jira/browse/SOLR-11503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16238729#comment-16238729 ] ASF subversion and git services commented on SOLR-11503: Commit 192204c29219e65ba5d240118de135bf28e726af in lucene-solr's branch refs/heads/branch_7x from [~erickerickson] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=192204c ] SOLR-11503: Collections created with legacyCloud=true cannot be opened if legacyCloud=false (cherry picked from commit d501ecd) > Collections created with legacyCloud=true cannot be opened if > legacyCloud=false > --- > > Key: SOLR-11503 > URL: https://issues.apache.org/jira/browse/SOLR-11503 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Critical > Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, > SOLR-11503.patch > > > SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a > collection with legacyCloud=true then switch to legacyCloud=false, you get an > NPE because coreNodeName is not defined in core.properties. > Since the default for legacyCloud changed from true to false between 6.6.1 > and 7.x, this means that any attempt to upgrade Solr with existing > collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value > for legacyCloud is used in both. Collections created with 6.6.0 would work. > Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work. > This is not as egregious with any collections *created with 7.0* since if the > default legacyCloud=false is present when the core is created, properties are > persisted with coreNodeName. However, if someone switches legacyCloud to > true, then creates a collection, then changes legacyCloud back to false then > they'll hit this even in 7.0+ > This happened because bit of reordering switched the order of the calls > below. coreNodeName is added to the descriptor in > create/createFromDescriptor(this, cd) via zkContgroller.preRegister so > coresLocator.create(this, cd) persists core.properties without coreNodeName. > _original order_ > SolrCore core = createFromDescriptor(cd, true, newCollection); > coresLocator.create(this, cd); > (NOTE: private calls to create were renamed to createFromDescriptor in > SOLR-11122). > I've got a fix in the works for creating cores, I'll attach a preliminary > patch w/o tests in a bit for discussion, but the question is really what to > do about 6.6.1 and 6.6.2 and 7.1 for that matter. > This is compounded by the fact that with the CVE, there's strong incentive to > move to 6.6.2. sgh. > There are two parts to fixing this completely: > 1> create core.properties correctly > 2> deal with coreNodeName not being in the core.properties file by going to > ZK and getting it (and persisting it). Haven't worked that part out yet > though, not in the first patch. Note one point here if it works as I hope it > will update the core.properties files first time they're opened. > Options that I see, there are really two parts: > *part1 create the core.properties correctly* > > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem. > > Recommend people not install 7x over collections created with 6x until they > > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and > > creating collections is at your own risk. > > Recommend that people change legacyCloud=true in 7.x until they start > > working with a fixed version, which one TBD. > *part2 deal with coreNodeName not being in the core.properties* > > Not backport and release with 7.2? set legacyCloud=true until then. > > Backport to point releases like 7.1.1? 6.6.3? > > and what about 7.0? I don't think many people will be affected by 7.0 since > > 7.1 came out so soon after. And setting legacyCloud=true will let people > > get by. > Fixing the two parts is not a question, they both need to be fixed. The real > question is whether we need to create a point release that incorporates one > or both or whether saying "you must set legacyCloud=true prior to Solr > version 7.# in order to work with any collections created with Solr versions > 6.6.1 through 7.#". > Let's hear opinions.. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false
[ https://issues.apache.org/jira/browse/SOLR-11503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16238723#comment-16238723 ] ASF subversion and git services commented on SOLR-11503: Commit d501ecd2d1d7e25a73e9cf475d8b8db525d5d42e in lucene-solr's branch refs/heads/master from [~erickerickson] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d501ecd ] SOLR-11503: Collections created with legacyCloud=true cannot be opened if legacyCloud=false > Collections created with legacyCloud=true cannot be opened if > legacyCloud=false > --- > > Key: SOLR-11503 > URL: https://issues.apache.org/jira/browse/SOLR-11503 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Critical > Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch, > SOLR-11503.patch > > > SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a > collection with legacyCloud=true then switch to legacyCloud=false, you get an > NPE because coreNodeName is not defined in core.properties. > Since the default for legacyCloud changed from true to false between 6.6.1 > and 7.x, this means that any attempt to upgrade Solr with existing > collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value > for legacyCloud is used in both. Collections created with 6.6.0 would work. > Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work. > This is not as egregious with any collections *created with 7.0* since if the > default legacyCloud=false is present when the core is created, properties are > persisted with coreNodeName. However, if someone switches legacyCloud to > true, then creates a collection, then changes legacyCloud back to false then > they'll hit this even in 7.0+ > This happened because bit of reordering switched the order of the calls > below. coreNodeName is added to the descriptor in > create/createFromDescriptor(this, cd) via zkContgroller.preRegister so > coresLocator.create(this, cd) persists core.properties without coreNodeName. > _original order_ > SolrCore core = createFromDescriptor(cd, true, newCollection); > coresLocator.create(this, cd); > (NOTE: private calls to create were renamed to createFromDescriptor in > SOLR-11122). > I've got a fix in the works for creating cores, I'll attach a preliminary > patch w/o tests in a bit for discussion, but the question is really what to > do about 6.6.1 and 6.6.2 and 7.1 for that matter. > This is compounded by the fact that with the CVE, there's strong incentive to > move to 6.6.2. sgh. > There are two parts to fixing this completely: > 1> create core.properties correctly > 2> deal with coreNodeName not being in the core.properties file by going to > ZK and getting it (and persisting it). Haven't worked that part out yet > though, not in the first patch. Note one point here if it works as I hope it > will update the core.properties files first time they're opened. > Options that I see, there are really two parts: > *part1 create the core.properties correctly* > > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem. > > Recommend people not install 7x over collections created with 6x until they > > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and > > creating collections is at your own risk. > > Recommend that people change legacyCloud=true in 7.x until they start > > working with a fixed version, which one TBD. > *part2 deal with coreNodeName not being in the core.properties* > > Not backport and release with 7.2? set legacyCloud=true until then. > > Backport to point releases like 7.1.1? 6.6.3? > > and what about 7.0? I don't think many people will be affected by 7.0 since > > 7.1 came out so soon after. And setting legacyCloud=true will let people > > get by. > Fixing the two parts is not a question, they both need to be fixed. The real > question is whether we need to create a point release that incorporates one > or both or whether saying "you must set legacyCloud=true prior to Solr > version 7.# in order to work with any collections created with Solr versions > 6.6.1 through 7.#". > Let's hear opinions.. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11503) Collections created with legacyCloud=true cannot be opened if legacyCloud=false
[ https://issues.apache.org/jira/browse/SOLR-11503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16236888#comment-16236888 ] Erick Erickson commented on SOLR-11503: --- Since there are no objections I'll commit this tomorrow. I'll remove the nocommit (just verified that the error still occurs if I comment the fixes out), and I'll add a CHANGES.txt before putting up the final patch. Final patch will have no code changes, just comment changes. > Collections created with legacyCloud=true cannot be opened if > legacyCloud=false > --- > > Key: SOLR-11503 > URL: https://issues.apache.org/jira/browse/SOLR-11503 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.6.1 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Critical > Attachments: SOLR-11503.patch, SOLR-11503.patch, SOLR-11503.patch > > > SOLR-11122 introduced a bug starting with 6.6.1 that means if you create a > collection with legacyCloud=true then switch to legacyCloud=false, you get an > NPE because coreNodeName is not defined in core.properties. > Since the default for legacyCloud changed from true to false between 6.6.1 > and 7.x, this means that any attempt to upgrade Solr with existing > collections *created with Solr 6.6.1 or 6.6.2 will fail* if the default value > for legacyCloud is used in both. Collections created with 6.6.0 would work. > Collections created in 6.6.1 or 6.6.2 with legacyCloud=false will work. > This is not as egregious with any collections *created with 7.0* since if the > default legacyCloud=false is present when the core is created, properties are > persisted with coreNodeName. However, if someone switches legacyCloud to > true, then creates a collection, then changes legacyCloud back to false then > they'll hit this even in 7.0+ > This happened because bit of reordering switched the order of the calls > below. coreNodeName is added to the descriptor in > create/createFromDescriptor(this, cd) via zkContgroller.preRegister so > coresLocator.create(this, cd) persists core.properties without coreNodeName. > _original order_ > SolrCore core = createFromDescriptor(cd, true, newCollection); > coresLocator.create(this, cd); > (NOTE: private calls to create were renamed to createFromDescriptor in > SOLR-11122). > I've got a fix in the works for creating cores, I'll attach a preliminary > patch w/o tests in a bit for discussion, but the question is really what to > do about 6.6.1 and 6.6.2 and 7.1 for that matter. > This is compounded by the fact that with the CVE, there's strong incentive to > move to 6.6.2. sgh. > There are two parts to fixing this completely: > 1> create core.properties correctly > 2> deal with coreNodeName not being in the core.properties file by going to > ZK and getting it (and persisting it). Haven't worked that part out yet > though, not in the first patch. Note one point here if it works as I hope it > will update the core.properties files first time they're opened. > Options that I see, there are really two parts: > *part1 create the core.properties correctly* > > Release 6.6.3, and/or 7.1.1 with this fix. This still leaves 7.0 a problem. > > Recommend people not install 7x over collections created with 6x until they > > have a version with fixes (7.1.1? 7.2?). Switching legacyCloud values and > > creating collections is at your own risk. > > Recommend that people change legacyCloud=true in 7.x until they start > > working with a fixed version, which one TBD. > *part2 deal with coreNodeName not being in the core.properties* > > Not backport and release with 7.2? set legacyCloud=true until then. > > Backport to point releases like 7.1.1? 6.6.3? > > and what about 7.0? I don't think many people will be affected by 7.0 since > > 7.1 came out so soon after. And setting legacyCloud=true will let people > > get by. > Fixing the two parts is not a question, they both need to be fixed. The real > question is whether we need to create a point release that incorporates one > or both or whether saying "you must set legacyCloud=true prior to Solr > version 7.# in order to work with any collections created with Solr versions > 6.6.1 through 7.#". > Let's hear opinions.. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
