pull replication from non-gerrit source when multisite refdb is enabled

[Raghul]

Hi all,

Is it possible to use pull replication to replicate from non-gerrit source when the multisite refdb is enabled? 

I have a test gerrit setup with two gerrit instances and the multi-site plugin configured.  
The pull replication plugin is also configured to replicate all projects between the two instances.


gerrit-1 <---> gerrit-2

The two instances have a project called "TEST".  We also have an non-gerrit code hosting platform which has the same repo TEST. I am trying to configure the pull replication plugin to replicate TEST from the non-gerrit repo.

non-gerrit  <-- pull TEST ---  gerrit-1 <---> gerrit-2

In the pull replication configuration, I have this stanza to pull from this non-gerrit remote.

[remote "TEST"]
        url = ssh://<non-gerrit-remote-url>/source/test.git
        projects = TEST
        fetch = +refs/heads/*:refs/heads/*
        fetchEvery = 60s
        mirror = true
rescheduleDelay = 15

However when I try to start pull replication for this remote, I get the following message in the replication log.

> TEST:refs/heads/main=<commit-sha> is already up-to-date with the shared-refdb and thus will NOT BE fetched

As I understand, this is the pull replication filter from the multisite plugin trying to prevent a split brain. 

> Incoming replication of refs that locally are already up-to-date with the global-refdb will be discarded, because they would not add anything more to the current status of the local refs.

However this is not a split brain, the non-gerrit remote is ahead, and ideally the refs should be pulled from the non-gerrit remote.

Is it possible to use pull replication to replicate from non-gerrit source when the multisite refdb is enabled? I do not see any config options in either the pull replication or multisite plugins that can exclude the non-gerrit remote from being filtered.

[Luca Milanesio]

On 24 Sep 2025, at 16:30, Raghul <ragh...@gmail.com> wrote:

Hi all,

Is it possible to use pull replication to replicate from non-gerrit source when the multisite refdb is enabled? 

Interesting, can you describe your specific use-case and the rationale behind it?

I have a test gerrit setup with two gerrit instances and the multi-site plugin configured.  
The pull replication plugin is also configured to replicate all projects between the two instances.


gerrit-1 <---> gerrit-2

The two instances have a project called "TEST".  We also have an non-gerrit code hosting platform which has the same repo TEST. I am trying to configure the pull replication plugin to replicate TEST from the non-gerrit repo.

non-gerrit  <-- pull TEST ---  gerrit-1 <---> gerrit-2

In the pull replication configuration, I have this stanza to pull from this non-gerrit remote.

[remote "TEST"]
        url = ssh://<non-gerrit-remote-url>/source/test.git
        projects = TEST
        fetch = +refs/heads/*:refs/heads/*
        fetchEvery = 60s
        mirror = true
rescheduleDelay = 15

However when I try to start pull replication for this remote, I get the following message in the replication log.

> TEST:refs/heads/main=<commit-sha> is already up-to-date with the shared-refdb and thus will NOT BE fetched

Well, what would you expect to fetch if your local ref is already up-to-date?

Please clarify your exactly real-life use case, as I do not see the rationale of fetching something if you are up-to-date.

As I understand, this is the pull replication filter from the multisite plugin trying to prevent a split brain. 

> Incoming replication of refs that locally are already up-to-date with the global-refdb will be discarded, because they would not add anything more to the current status of the local refs.

However this is not a split brain, the non-gerrit remote is ahead, and ideally the refs should be pulled from the non-gerrit remote.

How do you know that is ahead?

Is the remote non-gerrit remote updating the global refdb?

Is it possible to use pull replication to replicate from non-gerrit source when the multisite refdb is enabled? I do not see any config options in either the pull replication or multisite plugins that can exclude the non-gerrit remote from being filtered.

Explain in details your use-case and I’ll try to help at my best with a solution.

Luca.

[Raghul]

Hi Luca,

Thank you for the response.

Interesting, can you describe your specific use-case and the rationale behind it?

Explain in details your use-case and I’ll try to help at my best with a solution.

 
We have been using a non-gerrit code review tool and remote git server for years now. We are currently in the process of migrating to Gerrit.
We plan to use both the non-gerrit code review tool and gerrit simultaneously during the migration period.

We'd been using pull replication to pull in refs from the non-Gerrit remote in order to keep Gerrit in sync.

We're also looking to enable HA, hence I was testing the multi-site plugin, and noticed that enabling the global refdb blocked pull replication from the non-Gerrit remote. 

Well, what would you expect to fetch if your local ref is already up-to-date?

Please clarify your exactly real-life use case, as I do not see the rationale of fetching something if you are up-to-date.

How do you know that is ahead?

Is the remote non-gerrit remote updating the global refdb?

The non-gerrit remote is not updating the global refdb. It is not aware of the shared global refdb. There is no way for the gerrit instance to know that the non-gerrit remote is ahead. 

So I was looking for a way to configure the global refdb filter, and allow the pull replication plugin to import new commits from the non-gerrit remote.

But If that is not possible, it sounds like pushing from the non-gerrit remote to Gerrit (rather than pulling from gerrit) would be a solution to keep Gerrit in sync, and also have a multi-site setup? 

Raghul.

[Luca Milanesio]

Hi Raghul,

Thanks for the background information, which is really useful to understand the context.

On 26 Sep 2025, at 11:26, Raghul <ragh...@gmail.com> wrote:

Hi Luca,

Thank you for the response.

Interesting, can you describe your specific use-case and the rationale behind it?

Explain in details your use-case and I’ll try to help at my best with a solution.

 
We have been using a non-gerrit code review tool and remote git server for years now. We are currently in the process of migrating to Gerrit.
We plan to use both the non-gerrit code review tool and gerrit simultaneously during the migration period.

Unfortunately that isn’t going to work for you.

You cannot really push to the non-Gerrit Git server *and* to Gerrit simultaneously and expect the “magic” to happen by the pull-replication plugin.

What you are planning to do is basically a split-brain, and the multi-site setup would not allow that to happen, thanks to the check on the global-refdb consistency.

Your “problem” is therefore a “feature” and is the way it must work to avoid split-brains.

We'd been using pull replication to pull in refs from the non-Gerrit remote in order to keep Gerrit in sync.

That won’t work as discussed above.

We're also looking to enable HA, hence I was testing the multi-site plugin, and noticed that enabling the global refdb blocked pull replication from the non-Gerrit remote. 

Well, what would you expect to fetch if your local ref is already up-to-date?

Please clarify your exactly real-life use case, as I do not see the rationale of fetching something if you are up-to-date.

How do you know that is ahead?

Is the remote non-gerrit remote updating the global refdb?

The non-gerrit remote is not updating the global refdb. It is not aware of the shared global refdb. There is no way for the gerrit instance to know that the non-gerrit remote is ahead. 

Exactly, then how can the non-Gerrit remote get the commits from Gerrit?

It won’t, therefore it would create an “alternative history” and push that one back to Gerrit, causing a split-brain and potentially the risk to lose the changes made in Gerrit.

So I was looking for a way to configure the global refdb filter, and allow the pull replication plugin to import new commits from the non-gerrit remote.

This isn’t a problem about the global-refdb filter, but rather an overall cutover planning problem.

What is the non-Gerrit system you are migrating?

Maybe there is something that is possible to be done *there* for updating the global-refdb and avoiding Gerrit to update the same refs.

But If that is not possible, it sounds like pushing from the non-gerrit remote to Gerrit (rather than pulling from gerrit) would be a solution to keep Gerrit in sync, and also have a multi-site setup? 

No, that would still create the same issue.

Gerrit in multi-site won’t accept pushes that are not part of the same “history”, for preventing split-brain.

I believe you may need a bit of help in the design of the solution and put together a cutover plan.

Have you been consulted by any senior Gerrit or Git engineer on that?

HTH

Luca.

[Luca Milanesio]

On 26 Sep 2025, at 11:48, Luca Milanesio <luca.mi...@gmail.com> wrote:

Hi Raghul,

Thanks for the background information, which is really useful to understand the context.

On 26 Sep 2025, at 11:26, Raghul <ragh...@gmail.com> wrote:

Hi Luca,

Thank you for the response.

Interesting, can you describe your specific use-case and the rationale behind it?

Explain in details your use-case and I’ll try to help at my best with a solution.

 
We have been using a non-gerrit code review tool and remote git server for years now. We are currently in the process of migrating to Gerrit.
We plan to use both the non-gerrit code review tool and gerrit simultaneously during the migration period.

Unfortunately that isn’t going to work for you.

You cannot really push to the non-Gerrit Git server *and* to Gerrit simultaneously and expect the “magic” to happen by the pull-replication plugin.

What you are planning to do is basically a split-brain, and the multi-site setup would not allow that to happen, thanks to the check on the global-refdb consistency.

Your “problem” is therefore a “feature” and is the way it must work to avoid split-brains.

We'd been using pull replication to pull in refs from the non-Gerrit remote in order to keep Gerrit in sync.

That won’t work as discussed above.

How did you resolve the case where:

1) User A pushes a commit on branch ‘main’ on non-Gerrit

2) User B pushes a commit on branch ‘main’ on Gerrit

Now, the 1) and 2) happen at the same time, and you have to replicate from non-Gerrit to Gerrit

Either using push or pull replication won’t work as you would have lost either the commit from User A or the one from User B.

Have you thought about the above situation?

That’s what is technically referred as “split-brain”, which the global-refdb prevent from happening.

Hope this clarifies.

Luca.