New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Released
Owner:
Closed: Mar 29
Cc:
Components:



Sign in to add a comment

Reindexing an initialized site configured with elasticsearch index leads to unusable gerrit_index.config

Project Member Reported by marco.mm...@gmail.com, Mar 15

Issue description

*****************************************************************
*****                                                       *****
***** !!!! THIS BUG TRACKER IS FOR GERRIT CODE REVIEW !!!!  *****
*****                                                       *****
***** DO NOT SUBMIT BUGS FOR CHROME, ANDROID, CYANOGENMOD,  *****
***** INTERNAL ISSUES WITH YOUR COMPANY'S GERRIT SETUP, ETC.*****
*****                                                       *****
*****   THOSE ISSUES BELONG IN DIFFERENT ISSUE TRACKERS     *****
*****                                                       *****
*****************************************************************

Affected Version: 2.14

What steps will reproduce the problem?
1. Assume the usage of the currently open change [1].
2. Initialize a gerrit test site, configure it with elasticsearch index type.
3. Try to start that gerrit site; error_log failure says to reindex first.
4. Reindex as told.
5. Try to start that gerrit site; error_log failure says to reindex first (again).
6. Notice the breaking difference -below- in gerrit_index.config generated during step 4. (above).

[1] https://gerrit-review.googlesource.com/c/gerrit/+/165852
<=> "InitIndex: Set Elasticsearch index config under elasticsearch section".

What is the expected output?
gerrit_testsite/index/gerrit_index.config:
[index "accounts_0004"]
	ready = true
[index "changes_0039"]
	ready = true
[index "groups_0002"]
	ready = true
[index "gerrit2.14_accounts_0004_0004"]
	ready = true
[index "gerrit2.14_groups_0002_0002"]
	ready = true
[index "gerrit2.14_changes_0039_0039"]
	ready = true
[index "changes_0032"]
	ready = false
[index "changes_0033"]
	ready = false
[index "changes_0034"]
	ready = false
[index "changes_0035"]
	ready = false
[index "changes_0036"]
	ready = false
[index "changes_0037"]
	ready = false
[index "changes_0038"]
	ready = false
[index "groups_0001"]
	ready = false
[index "accounts_0001"]
	ready = false
[index "accounts_0002"]
	ready = false
[index "accounts_0003"]
	ready = false

What do you see instead?
gerrit_testsite/index/gerrit_index.config:
[index "gerritaccounts_0004_0004"]
	ready = true
[index "gerritgroups_0002_0002"]
	ready = true
[index "gerritchanges_0039_0039"]
	ready = true

Please provide any additional information below.
Workaround is to use the aforementioned expected gerrit_index.config, as opposed to leaving the broken one (above) active -upon starting that gerrit site.
 

Comment 1 Deleted

Comment 2 Deleted

Project Member

Comment 3 by huga...@gmail.com, Mar 15

Sorry for the spam... take 3 for my comment :)

I think the expected output is not right, I see both lucene and elasticsearch in there. Does it work if you start the server with the following gerrit_testsite/index/gerrit_index.config?


[index "gerrit_accounts_0004"]
	ready = true
[index "gerrit_groups_0002"]
	ready = true
[index "gerrit_changes_0039"]
	ready = true


and content of gerrit.config is :

[index]
	type = ELASTICSEARCH
[elasticsearch]
	prefix = gerrit
[elasticsearch "default"]
	protocol = http
	hostname = localhost
	port = 9200
Project Member

Comment 4 by marco.mm...@gmail.com, Mar 15

Right, I was misled by my other, switched site (from lucene to elasticsearch) -for the expected index config that is. However, the above one you propose does not work as is; and, a reindex leads to the same course of events. Note: above, your prefix needs to be gerrit_ (with an explicit trailing underscore, for the site to start ok).

Here is an index config that currently works for me, with the false items automatically added by gerrit upon site start; not sure if that should be the formally expected one, though:

[index "accounts_0004"]
	ready = true
[index "groups_0002"]
	ready = true
[index "changes_0039"]
	ready = true
[index "gerrit_accounts_0004_0004"]
	ready = true
[index "gerrit_groups_0002_0002"]
	ready = true
[index "gerrit_changes_0039_0039"]
	ready = true
[index "changes_0032"]
	ready = false
[index "changes_0033"]
	ready = false
[index "changes_0034"]
	ready = false
[index "changes_0035"]
	ready = false
[index "changes_0036"]
	ready = false
[index "changes_0037"]
	ready = false
[index "changes_0038"]
	ready = false
[index "groups_0001"]
	ready = false
[index "accounts_0001"]
	ready = false
[index "accounts_0002"]
	ready = false
[index "accounts_0003"]
	ready = false

Status: Accepted (was: New)
Project Member

Comment 6 by marco.mm...@gmail.com, Mar 22

Status: Started (was: Accepted)
Project Member

Comment 7 by huga...@gmail.com, Mar 22

Owner: marco.mm...@gmail.com
Project Member

Comment 8 by marco.mm...@gmail.com, Mar 26

The work on this bug-fix is going well; more to come soon this week.
Project Member

Comment 9 by huga...@gmail.com, Mar 28

If I init an empty site with Lucene using gerrit 2.14, here is the gerrit gerrit_index.config:

[index "accounts_0004"]
        ready = true
[index "changes_0039"]
        ready = true
[index "groups_0002"]
        ready = true

I expect the same for Elasticsearch with the prefix as the only difference. So if my init of my empty site using Elasticsearch result in the following gerrit.config:

[elasticsearch]
        prefix = gerrit_
[elasticsearch "default"]
        protocol = http
        hostname = localhost
        port = 9200

Then the gerrit_index.config should look like this:

[index "gerrit_accounts_0004"]
        ready = true
[index "gerrit_changes_0039"]
        ready = true
[index "gerrit_groups_0002"]
        ready = true

I think there is more than one bug:
-init of an empty site is not even creating the gerrit_index.config
-Even if I create it manually during the init(right before admin user gets created), both reindex and Gerrit daemon expect the following config which is wrong(the second _version should not be there):

[index "gerrit_t2_accounts_0004_0004"]
        ready = true
[index "gerrit_t2_groups_0002_0002"]
        ready = true
[index "gerrit_t2_changes_0039_0039"]
        ready = true


Project Member

Comment 10 by marco.mm...@gmail.com, Mar 28

The latter is something that I currently have a fix for, yes (former as well). I still need to clean those acts up prior to pushing for review.

Concatenating the prefix and actual index name (with version) is currently done internally, i.e., without expecting any presence of the prefix -in gerrit_index.config that is.

And there are a few more bugs related to this issue overall (assuming we number the above listed ones as 1. and 2.):

3. the visually handy underscore between prefix and index name is missing if not explicitly configured as such; e.g., configuring 'gerrit' leads to 'gerritchanges_0039' -as opposed to 'gerrit_changes_0039';

4. as I start applying the fixes I'm currently drafting for the above listed bugs (so-numbered 1. and 2.), I get more (unready) index versions generated in gerrit_index.config: so on top of the expected ones, I get all the previous known schema versions in as ready = false; I currently have an unclean fix for that as well.

-Will keep this thread posted as I progress on cleaning up and confirming my fixes for all those (and maybe more emerging) issues, then.
Project Member

Comment 11 by marco.mm...@gmail.com, Mar 28

Addendum: currently working on also creating the changes index in elasticsearch during init, on top of the already created accounts and groups indices. Otherwise, browsing the initialized site straight away logs an error, about not finding that index (in elasticsearch).

That happens when starting to apply some of the fixes for the other (above listed /related) bugs.
Project Member

Comment 12 by marco.mm...@gmail.com, Mar 28

Status: ChangeUnderReview (was: Started)
https://gerrit-review.googlesource.com/#/c/gerrit/+/169130

Project Member

Comment 13 by huga...@gmail.com, Mar 29

Labels: FixedIn-2.14.8
Status: Submitted (was: ChangeUnderReview)
Labels: FixedIn-2.15.2
Status: Released (was: Submitted)
Status: Submitted (was: Released)
Accidentally set to released because a search for label:FixedIn-2.15 also includes the ones with FixedIn-2.15.2
Status: Released (was: Submitted)

Sign in to add a comment