[jira] [Comment Edited] (SOLR-12182) Can not switch urlScheme in 7x if there are any cores in the cluster

2020-04-21 Thread Martin Entwistle (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088469#comment-17088469
 ] 

Martin Entwistle edited comment on SOLR-12182 at 4/21/20, 9:18 AM:
---

I am having issues applying this patch though, it does not look complete to me, 
and git says:

{{Only garbage was found in the patch input.}}


 Can anyone else try this out and let me know if it is possible to apply the 
patch (and to what branch)


was (Author: martinentwistle):
I am having issues applying this patch though, it does not look complete to me, 
and git says
 Only garbage was found in the patch input.
Can anyone else try this out and let me know if it is possible to apply the 
patch (and to what branch)

> Can not switch urlScheme in 7x if there are any cores in the cluster
> 
>
> Key: SOLR-12182
> URL: https://issues.apache.org/jira/browse/SOLR-12182
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.0, 7.1, 7.2
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-12182.patch
>
>
> I was trying to enable TLS on a cluster that was already in use i.e. had 
> existing collections and ended up with down cores, that wouldn't come up and 
> the following core init errors in the logs:
> *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> replica with coreNodeName core_node4 exists but with a different name or 
> base_url.*
> What is happening here is that the core/replica is defined in the 
> clusterstate with the urlScheme as part of it's base URL e.g. 
> *"base_url":"http:hostname:port/solr"*.
> Switching the urlScheme in Solr breaks this convention as the host now uses 
> HTTPS instead.
> Actually, I ran into this with an older version because I was running with 
> *legacyCloud=false* and then realized that we switched that to the default 
> behavior only in 7x i.e while most users did not hit this issue with older 
> versions, unless they overrode the legacyCloud value explicitly, users 
> running 7x are bound to run into this more often.
> Switching the value of legacyCloud to true, bouncing the cluster so that the 
> clusterstate gets flushed, and then setting it back to false is a workaround 
> but a bit risky one if you don't know if you have any old cores lying around.
> Ideally, I think we shouldn't prepend the urlScheme to the base_url value and 
> use the urlScheme on the fly to construct it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org



[jira] [Commented] (SOLR-12182) Can not switch urlScheme in 7x if there are any cores in the cluster

2020-04-21 Thread Martin Entwistle (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088469#comment-17088469
 ] 

Martin Entwistle commented on SOLR-12182:
-

I am having issues applying this patch though, it does not look complete to me, 
and git says
 Only garbage was found in the patch input.
Can anyone else try this out and let me know if it is possible to apply the 
patch (and to what branch)

> Can not switch urlScheme in 7x if there are any cores in the cluster
> 
>
> Key: SOLR-12182
> URL: https://issues.apache.org/jira/browse/SOLR-12182
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.0, 7.1, 7.2
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-12182.patch
>
>
> I was trying to enable TLS on a cluster that was already in use i.e. had 
> existing collections and ended up with down cores, that wouldn't come up and 
> the following core init errors in the logs:
> *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> replica with coreNodeName core_node4 exists but with a different name or 
> base_url.*
> What is happening here is that the core/replica is defined in the 
> clusterstate with the urlScheme as part of it's base URL e.g. 
> *"base_url":"http:hostname:port/solr"*.
> Switching the urlScheme in Solr breaks this convention as the host now uses 
> HTTPS instead.
> Actually, I ran into this with an older version because I was running with 
> *legacyCloud=false* and then realized that we switched that to the default 
> behavior only in 7x i.e while most users did not hit this issue with older 
> versions, unless they overrode the legacyCloud value explicitly, users 
> running 7x are bound to run into this more often.
> Switching the value of legacyCloud to true, bouncing the cluster so that the 
> clusterstate gets flushed, and then setting it back to false is a workaround 
> but a bit risky one if you don't know if you have any old cores lying around.
> Ideally, I think we shouldn't prepend the urlScheme to the base_url value and 
> use the urlScheme on the fly to construct it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org



[jira] [Commented] (SOLR-12182) Can not switch urlScheme in 7x if there are any cores in the cluster

2020-04-21 Thread Martin Entwistle (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088466#comment-17088466
 ] 

Martin Entwistle commented on SOLR-12182:
-

I would like to try and address this issue as it is hitting us.  We would like 
to be able to create collections and test them out, then turn on SSL later. 

> Can not switch urlScheme in 7x if there are any cores in the cluster
> 
>
> Key: SOLR-12182
> URL: https://issues.apache.org/jira/browse/SOLR-12182
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 7.0, 7.1, 7.2
>Reporter: Anshum Gupta
>Priority: Major
> Attachments: SOLR-12182.patch
>
>
> I was trying to enable TLS on a cluster that was already in use i.e. had 
> existing collections and ended up with down cores, that wouldn't come up and 
> the following core init errors in the logs:
> *org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
> replica with coreNodeName core_node4 exists but with a different name or 
> base_url.*
> What is happening here is that the core/replica is defined in the 
> clusterstate with the urlScheme as part of it's base URL e.g. 
> *"base_url":"http:hostname:port/solr"*.
> Switching the urlScheme in Solr breaks this convention as the host now uses 
> HTTPS instead.
> Actually, I ran into this with an older version because I was running with 
> *legacyCloud=false* and then realized that we switched that to the default 
> behavior only in 7x i.e while most users did not hit this issue with older 
> versions, unless they overrode the legacyCloud value explicitly, users 
> running 7x are bound to run into this more often.
> Switching the value of legacyCloud to true, bouncing the cluster so that the 
> clusterstate gets flushed, and then setting it back to false is a workaround 
> but a bit risky one if you don't know if you have any old cores lying around.
> Ideally, I think we shouldn't prepend the urlScheme to the base_url value and 
> use the urlScheme on the fly to construct it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org