Rolling upgrades from 5.x to 6.0

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Rolling upgrades from 5.x to 6.0

Shai Erera
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Mark Miller-3
Yes, we are allowed wide berth to break backcompat across major versions and we cannot support rolling updates for the same reason Lucene stopped trying to do full back compat across major versions. Without, we can't properly innovate in the code or fix past mistakes and would also burn lots of cycles we don't have on crazy, "sophisticated" back compat layers.

We don't even really support rolling updates between major versions. We make a simple best effort. Until we have tests, it's going to be a shaky affair. There is a JIRA open now working on some testing I believe.

- Mark

On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <[hidden email]> wrote:
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
--
Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Mark Miller-3
I should say, without good reason, I think we do try to make the upgrade as easy as possible.

- Mark

On Tue, Feb 23, 2016 at 12:00 PM Mark Miller <[hidden email]> wrote:
Yes, we are allowed wide berth to break backcompat across major versions and we cannot support rolling updates for the same reason Lucene stopped trying to do full back compat across major versions. Without, we can't properly innovate in the code or fix past mistakes and would also burn lots of cycles we don't have on crazy, "sophisticated" back compat layers.

We don't even really support rolling updates between major versions. We make a simple best effort. Until we have tests, it's going to be a shaky affair. There is a JIRA open now working on some testing I believe.

- Mark

On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <[hidden email]> wrote:
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
--
--
Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Shai Erera
In reply to this post by Mark Miller-3
Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't guarantee support for is API, which isn't the case here.

So what's in 6.0 that can't read a 5.x Solr. It can't be the index format since that's supported by Lucene. Is it the ZK format? If so, should we try to "version" it so that a 6.0 code can read a 5.x version? Is it something else / additionally?

Shai

On Tue, Feb 23, 2016 at 7:06 PM Mark Miller <[hidden email]> wrote:
Yes, we are allowed wide berth to break backcompat across major versions and we cannot support rolling updates for the same reason Lucene stopped trying to do full back compat across major versions. Without, we can't properly innovate in the code or fix past mistakes and would also burn lots of cycles we don't have on crazy, "sophisticated" back compat layers.

We don't even really support rolling updates between major versions. We make a simple best effort. Until we have tests, it's going to be a shaky affair. There is a JIRA open now working on some testing I believe.

- Mark

On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <[hidden email]> wrote:
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
--
Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Mark Miller-3

On Tue, Feb 23, 2016 at 1:27 PM Shai Erera <[hidden email]> wrote:
Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't guarantee support for is API, which isn't the case here.

Of course with Lucene I mean API back compat. Both Lucene and Solr support indexes over major versions. We don't promise anything else.
 

So what's in 6.0 that can't read a 5.x Solr. It can't be the index format since that's supported by Lucene. Is it the ZK format? If so, should we try to "version" it so that a 6.0 code can read a 5.x version? Is it something else / additionally?

We are free to change whatever we want subject to discussion on that issue. So I can't make a list :)

We don't have promises over a major version other than Lucenes index back comp promise.
 
- Mark
--
Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Mike Drob-3
In reply to this post by Shai Erera
A 5.x Solr could have indices that are still in a 4.x format, right? That would be one point where it's not "fully back compatible."

On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera <[hidden email]> wrote:
Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't guarantee support for is API, which isn't the case here.

So what's in 6.0 that can't read a 5.x Solr. It can't be the index format since that's supported by Lucene. Is it the ZK format? If so, should we try to "version" it so that a 6.0 code can read a 5.x version? Is it something else / additionally?

Shai

On Tue, Feb 23, 2016 at 7:06 PM Mark Miller <[hidden email]> wrote:
Yes, we are allowed wide berth to break backcompat across major versions and we cannot support rolling updates for the same reason Lucene stopped trying to do full back compat across major versions. Without, we can't properly innovate in the code or fix past mistakes and would also burn lots of cycles we don't have on crazy, "sophisticated" back compat layers.

We don't even really support rolling updates between major versions. We make a simple best effort. Until we have tests, it's going to be a shaky affair. There is a JIRA open now working on some testing I believe.

- Mark

On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <[hidden email]> wrote:
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
--

Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Anshum Gupta
For that, we provide an index upgrade tool with 6.0, like we did in 5.0.

On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob <[hidden email]> wrote:
A 5.x Solr could have indices that are still in a 4.x format, right? That would be one point where it's not "fully back compatible."

On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera <[hidden email]> wrote:
Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't guarantee support for is API, which isn't the case here.

So what's in 6.0 that can't read a 5.x Solr. It can't be the index format since that's supported by Lucene. Is it the ZK format? If so, should we try to "version" it so that a 6.0 code can read a 5.x version? Is it something else / additionally?

Shai

On Tue, Feb 23, 2016 at 7:06 PM Mark Miller <[hidden email]> wrote:
Yes, we are allowed wide berth to break backcompat across major versions and we cannot support rolling updates for the same reason Lucene stopped trying to do full back compat across major versions. Without, we can't properly innovate in the code or fix past mistakes and would also burn lots of cycles we don't have on crazy, "sophisticated" back compat layers.

We don't even really support rolling updates between major versions. We make a simple best effort. Until we have tests, it's going to be a shaky affair. There is a JIRA open now working on some testing I believe.

- Mark

On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <[hidden email]> wrote:
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
--




--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Shai Erera
Mark, I understand that we currently don't have any other promises :). I asked in case you happen to know that "oh yeah, in 6.0 we've changed ZK to refer to /solr_collections instead of /collections" (I wish it would be *that* trivial :)).

If you don't have a list that's fine. You just sounded really confident that 5.x -> 6.0 won't work, so I hoped you also can tell why.

I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can read a 5.0 (or 6.0) Solr. If ZK is our "format", then we should treat it as a thing we want to support. That's just my opinion though.

Shai

On Tue, Feb 23, 2016 at 8:46 PM Anshum Gupta <[hidden email]> wrote:
For that, we provide an index upgrade tool with 6.0, like we did in 5.0.

On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob <[hidden email]> wrote:
A 5.x Solr could have indices that are still in a 4.x format, right? That would be one point where it's not "fully back compatible."

On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera <[hidden email]> wrote:
Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't guarantee support for is API, which isn't the case here.

So what's in 6.0 that can't read a 5.x Solr. It can't be the index format since that's supported by Lucene. Is it the ZK format? If so, should we try to "version" it so that a 6.0 code can read a 5.x version? Is it something else / additionally?

Shai

On Tue, Feb 23, 2016 at 7:06 PM Mark Miller <[hidden email]> wrote:
Yes, we are allowed wide berth to break backcompat across major versions and we cannot support rolling updates for the same reason Lucene stopped trying to do full back compat across major versions. Without, we can't properly innovate in the code or fix past mistakes and would also burn lots of cycles we don't have on crazy, "sophisticated" back compat layers.

We don't even really support rolling updates between major versions. We make a simple best effort. Until we have tests, it's going to be a shaky affair. There is a JIRA open now working on some testing I believe.

- Mark

On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <[hidden email]> wrote:
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
--




--
Anshum Gupta
Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Jan Høydahl / Cominvent
I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can read a 5.0 (or 6.0) Solr.

Agree. A lack of promise for major version back compat gives us the freedom to do crazy breaking changes - but it does not prevent us from doing best effort attempts of a smooth transition for those that want to attempt.


To contribute constructively to the discussion, here is the current 6.0 upgrade instructions from CHANGES.txt, which may give some hints on possible hurdles:

Upgrading from Solr 5.x
----------------------

* The deprecated SolrServer and subclasses have been removed, use SolrClient
instead.

* The deprecated <nrtMode> configuration in solrconfig.xml has been removed.
Please remove it from solrconfig.xml.

* SolrClient.shutdown() has been removed, use SolrClient.close() instead.

* The deprecated zkCredientialsProvider element in solrcloud section of solr.xml
is now removed. Use the correct spelling (zkCredentialsProvider) instead.

* SOLR-7957: internal/expert - ResultContext was significantly changed and expanded
to allow for multiple full query results (DocLists) per Solr request.
TransformContext was rendered redundant and was removed. (yonik)

* Several changes have been made regarding the "Similarity" used in Solr, in order to provide
better default behavior for new users. There are 3 key impacts of these changes on existing
users who upgrade:
* DefaultSimilarityFactory has been removed. If you currently have DefaultSimilarityFactory explicitly
referenced in your schema.xml, edit your config to use the functionally identical
ClassicSimilarityFactory. See SOLR-8239 for more details.
* The implicit default Similarity used when no <similarity/> is configured in schema.xml has
been changed to SchemaSimilarityFactory. Users who wish to preserve back-compatible behavior should
either explicitly configure ClassicSimilarityFactory, or ensure that the luceneMatchVersion
for the collection is less then 6.0. See SOLR-8270 + SOLR-8271 for details.
* SchemaSimilarityFactory has been modified to use BM25Similarity as the default for fieldTypes that
do not explicitly declare a Similarity. The legacy behavior of using ClassicSimilarity as the
default will occur if the luceneMatchVersion for the collection is less then 6.0, or the
'defaultSimFromFieldType' configuration option may be used to specify any default of your choosing.
See SOLR-8261 + SOLR-8329 for more details.

* If your solrconfig.xml file doesn't explicitly mention the schemaFactory to use then Solr will choose
the ManagedIndexSchemaFactory by default. Previously it would have chosen ClassicIndexSchemaFactory.
This means that the Schema APIs ( /<collection>/schema ) are enabled and the schema is mutable.
When Solr starts your schema.xml file will be renamed to managed-schema. If you want to retain the old behaviour
then please ensure that the solrconfig.xml explicitly uses the ClassicIndexSchemaFactory :
<schemaFactory class="ClassicIndexSchemaFactory"/> or your luceneMatchVersion in the solrconfig.xml is less than 6.0

* SolrIndexSearcher.QueryCommand and QueryResult were moved to their own classes. If you reference them
in your code, you should import them under o.a.s.search (or use your IDE's "Organize Imports").

* SOLR-8698: 'useParams' attribute specified in request handler cannot be overridden from request params

Looks like many of these changes would be possible to prepare for by modifying 5.x config before upgrading, e.g. the schema factory etc.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

23. feb. 2016 kl. 19.54 skrev Shai Erera <[hidden email]>:

Mark, I understand that we currently don't have any other promises :). I asked in case you happen to know that "oh yeah, in 6.0 we've changed ZK to refer to /solr_collections instead of /collections" (I wish it would be *that* trivial :)).

If you don't have a list that's fine. You just sounded really confident that 5.x -> 6.0 won't work, so I hoped you also can tell why.

I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can read a 5.0 (or 6.0) Solr. If ZK is our "format", then we should treat it as a thing we want to support. That's just my opinion though.

Shai

On Tue, Feb 23, 2016 at 8:46 PM Anshum Gupta <[hidden email]> wrote:
For that, we provide an index upgrade tool with 6.0, like we did in 5.0.

On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob <[hidden email]> wrote:
A 5.x Solr could have indices that are still in a 4.x format, right? That would be one point where it's not "fully back compatible."

On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera <[hidden email]> wrote:
Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't guarantee support for is API, which isn't the case here.

So what's in 6.0 that can't read a 5.x Solr. It can't be the index format since that's supported by Lucene. Is it the ZK format? If so, should we try to "version" it so that a 6.0 code can read a 5.x version? Is it something else / additionally?

Shai

On Tue, Feb 23, 2016 at 7:06 PM Mark Miller <[hidden email]> wrote:
Yes, we are allowed wide berth to break backcompat across major versions and we cannot support rolling updates for the same reason Lucene stopped trying to do full back compat across major versions. Without, we can't properly innovate in the code or fix past mistakes and would also burn lots of cycles we don't have on crazy, "sophisticated" back compat layers.

We don't even really support rolling updates between major versions. We make a simple best effort. Until we have tests, it's going to be a shaky affair. There is a JIRA open now working on some testing I believe.

- Mark

On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <[hidden email]> wrote:
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
--




--
Anshum Gupta

Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Mark Miller-3
In reply to this post by Shai Erera
I'm not confident it won't work. I'm confident that it's not tested and any dev in any change someone is not paying attention to can make it not work. So to say it will work or to even count on it working is silly. The are tons of behavior changes beyond what's in ZK that could mess with rolling upgrades. We find issues doing non rolling upgrades on *point* releases in my experience.

The only way you will ever know is to test it out when the release happens, and even then, not every issue is easily caught by a simple test. Commands can come in during the rolling upgrade, certain features can be broken, etc, etc.

I would like to support rolling updates on point releases, that's def a goal, even that is still a bit of prayer as it's not properly tested and it can depend on what version you coming from and going to.

- Mark

On Tue, Feb 23, 2016 at 1:54 PM Shai Erera <[hidden email]> wrote:
Mark, I understand that we currently don't have any other promises :). I asked in case you happen to know that "oh yeah, in 6.0 we've changed ZK to refer to /solr_collections instead of /collections" (I wish it would be *that* trivial :)).

If you don't have a list that's fine. You just sounded really confident that 5.x -> 6.0 won't work, so I hoped you also can tell why.

I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can read a 5.0 (or 6.0) Solr. If ZK is our "format", then we should treat it as a thing we want to support. That's just my opinion though.

Shai

On Tue, Feb 23, 2016 at 8:46 PM Anshum Gupta <[hidden email]> wrote:
For that, we provide an index upgrade tool with 6.0, like we did in 5.0.

On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob <[hidden email]> wrote:
A 5.x Solr could have indices that are still in a 4.x format, right? That would be one point where it's not "fully back compatible."

On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera <[hidden email]> wrote:
Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't guarantee support for is API, which isn't the case here.

So what's in 6.0 that can't read a 5.x Solr. It can't be the index format since that's supported by Lucene. Is it the ZK format? If so, should we try to "version" it so that a 6.0 code can read a 5.x version? Is it something else / additionally?

Shai

On Tue, Feb 23, 2016 at 7:06 PM Mark Miller <[hidden email]> wrote:
Yes, we are allowed wide berth to break backcompat across major versions and we cannot support rolling updates for the same reason Lucene stopped trying to do full back compat across major versions. Without, we can't properly innovate in the code or fix past mistakes and would also burn lots of cycles we don't have on crazy, "sophisticated" back compat layers.

We don't even really support rolling updates between major versions. We make a simple best effort. Until we have tests, it's going to be a shaky affair. There is a JIRA open now working on some testing I believe.

- Mark

On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <[hidden email]> wrote:
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
--




--
Anshum Gupta
--
Reply | Threaded
Open this post in threaded view
|

Re: Rolling upgrades from 5.x to 6.0

Mark Miller-3
Of course there is nothing saying a new discussion changes all that and we choose to try and support rolling upgrades over major releases until we decide to have a *break* release or something. I'm just saying what is.

Rolling upgrades forever puts us in a tight spot like Lucene was in with API and runtime behavior previously.

At the same time, we probably will often go a couple release without doing things that require major breaks.

- Mark
On Tue, Feb 23, 2016 at 8:20 PM Mark Miller <[hidden email]> wrote:
I'm not confident it won't work. I'm confident that it's not tested and any dev in any change someone is not paying attention to can make it not work. So to say it will work or to even count on it working is silly. The are tons of behavior changes beyond what's in ZK that could mess with rolling upgrades. We find issues doing non rolling upgrades on *point* releases in my experience.

The only way you will ever know is to test it out when the release happens, and even then, not every issue is easily caught by a simple test. Commands can come in during the rolling upgrade, certain features can be broken, etc, etc.

I would like to support rolling updates on point releases, that's def a goal, even that is still a bit of prayer as it's not properly tested and it can depend on what version you coming from and going to.

- Mark


On Tue, Feb 23, 2016 at 1:54 PM Shai Erera <[hidden email]> wrote:
Mark, I understand that we currently don't have any other promises :). I asked in case you happen to know that "oh yeah, in 6.0 we've changed ZK to refer to /solr_collections instead of /collections" (I wish it would be *that* trivial :)).

If you don't have a list that's fine. You just sounded really confident that 5.x -> 6.0 won't work, so I hoped you also can tell why.

I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can read a 5.0 (or 6.0) Solr. If ZK is our "format", then we should treat it as a thing we want to support. That's just my opinion though.

Shai

On Tue, Feb 23, 2016 at 8:46 PM Anshum Gupta <[hidden email]> wrote:
For that, we provide an index upgrade tool with 6.0, like we did in 5.0.

On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob <[hidden email]> wrote:
A 5.x Solr could have indices that are still in a 4.x format, right? That would be one point where it's not "fully back compatible."

On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera <[hidden email]> wrote:
Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't guarantee support for is API, which isn't the case here.

So what's in 6.0 that can't read a 5.x Solr. It can't be the index format since that's supported by Lucene. Is it the ZK format? If so, should we try to "version" it so that a 6.0 code can read a 5.x version? Is it something else / additionally?

Shai

On Tue, Feb 23, 2016 at 7:06 PM Mark Miller <[hidden email]> wrote:
Yes, we are allowed wide berth to break backcompat across major versions and we cannot support rolling updates for the same reason Lucene stopped trying to do full back compat across major versions. Without, we can't properly innovate in the code or fix past mistakes and would also burn lots of cycles we don't have on crazy, "sophisticated" back compat layers.

We don't even really support rolling updates between major versions. We make a simple best effort. Until we have tests, it's going to be a shaky affair. There is a JIRA open now working on some testing I believe.

- Mark

On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <[hidden email]> wrote:
Hi

I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 isn't supported. Is it really the case? Does it mean that anyone who has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

If this is really the case, can someone list the known issues/reasons for that?Can we do something about it, e.g. in a subsequent 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling upgrades from pre-5.4 to 5.4)?

I feel it's odd (and may not be taken well) if we force users to take down their entire cluster if they want to upgrade to 6.0. Definitely feels like it will also slow down 6.0 adoption.

And if nothing can be done, what's the recommended way then to upgrade to 6.0?

Shai
--




--
Anshum Gupta
--
--