[
https://issues.apache.org/jira/browse/SOLR-14128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016115#comment-17016115
]
Andrzej Bialecki commented on SOLR-14128:
-----------------------------------------
So, in theory the sequence should be as follows:
* Overseer performs the back-compat check only when it starts (or actually
when a new leader is elected)
* a {{.system}} is created with the default schema, and a few docs are added
to make sure there's indexed data that conforms to the schema
* the schema is changed in an obviously incompatible way - "timestamp" is
changed from "tdate" to "string"
* existing Overseer leader is killed in order to force the leader election so
that the new overseer leader does the back-compat check.
In the past there was some funkiness around the schema update - occasionally it
would fail, or seemingly not take in... I don't see it here however, at least
not in the way it used to break.
So ... I'm not really sure what's happening here. Maybe we could start by not
killing the node that is hosting one of the replicas? That's what the
{{nodeset.patch}} does. Let's start with this change and see what happens (it
never fails locally for me...).
> SystemCollectionCompatTest times out waiting for Overseer to do compatibility
> checks
> ------------------------------------------------------------------------------------
>
> Key: SOLR-14128
> URL: https://issues.apache.org/jira/browse/SOLR-14128
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: fail.txt, nodeset.patch, pass.txt,
> thetaphi_Lucene-Solr-master-Linux_25161.log.txt
>
>
--
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
