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.

[Kenny Ho]

Hi Luca,

I understand what you said about split-brain between Gerrit and the non-Gerrit servers, but will the pull-replication plugin works with HA when the Gerrit repo is 'read-only'?  (i.e. read-only repos in HA Gerrit, pulling content from non-Gerrit server with pull-replication.)

Regards,

Kenny

[Luca Milanesio]

Hi Kenny,

Can you please avoid top-posting and use interleaved answers?
See [1].

> On 8 Oct 2025, at 13:27, Kenny Ho <y2k...@gmail.com> wrote:
>
> Hi Luca,
>
> I understand what you said about split-brain between Gerrit and the non-Gerrit servers, but will the pull-replication plugin works with HA when the Gerrit repo is 'read-only'?

Sure, that will work and pull from non-Gerrit servers without issues.

*IF* the repository is read-only, it means that all updates were made by non-Gerrit servers, therefore the global-refdb should be empty for those repos.

> (i.e. read-only repos in HA Gerrit, pulling content from non-Gerrit server with pull-replication.)
>
> Regards,
> Kenny
>
> On Friday, September 26, 2025 at 10:14:33 AM UTC-4 Luca Milanesio wrote:
>
>> 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.

@Kenny —> ^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^


If you push *both* to the Gerrit server repo/branch *AND* non-Gerrit server repo/branch, who knows which one is the *good* one?
You are basically creating a split-brain.

Hope this clarifies.

Luca.

[1] https://www.gerritcodereview.com/support.html#general-support

>>
>> 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.
>
>>
>>> 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.
>
>
>

> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/720e1254-548d-46f5-af2f-8e310564ebd7n%40googlegroups.com.

[Kenny Ho]

On Wednesday, October 8, 2025 at 8:37:41 AM UTC-4 Luca Milanesio wrote:

Hi Kenny,

Can you please avoid top-posting and use interleaved answers?
See [1].

My apology, I was typing from the Google Group web UI quickly.

 

> On 8 Oct 2025, at 13:27, Kenny Ho wrote:
>
> Hi Luca,
>
> I understand what you said about split-brain between Gerrit and the non-Gerrit servers, but will the pull-replication plugin works with HA when the Gerrit repo is 'read-only'?

Sure, that will work and pull from non-Gerrit servers without issues.

*IF* the repository is read-only, it means that all updates were made by non-Gerrit servers, therefore the global-refdb should be empty for those repos. 

I am not too familiar with Gerrit internal/global-refdb.  What would create entries in the global-refdb?  What if the 'read-only'-ness of the repo is by branch?  For example, branches from the non-Gerrit server will remain updated by that servers but the HA Gerrit will also have internal forks that does not exist on the non-Gerrit server.  Would this setup work?  It is definitely a split-brain at the repo level but perhaps not at the branch level?

Regards,

Kenny

[luca.mi...@gmail.com]

Sent from my iPhone

On 8 Oct 2025, at 15:34, Kenny Ho <y2k...@gmail.com> wrote:



On Wednesday, October 8, 2025 at 8:37:41 AM UTC-4 Luca Milanesio wrote:

Hi Kenny,

Can you please avoid top-posting and use interleaved answers?
See [1].

My apology, I was typing from the Google Group web UI quickly.

 

> On 8 Oct 2025, at 13:27, Kenny Ho wrote:
>
> Hi Luca,
>
> I understand what you said about split-brain between Gerrit and the non-Gerrit servers, but will the pull-replication plugin works with HA when the Gerrit repo is 'read-only'?

Sure, that will work and pull from non-Gerrit servers without issues.

*IF* the repository is read-only, it means that all updates were made by non-Gerrit servers, therefore the global-refdb should be empty for those repos. 

I am not too familiar with Gerrit internal/global-refdb.  What would create entries in the global-refdb? 

Creating commits in a mutable ref in Gerrit. Replication does not update the global-refdb

What if the 'read-only'-ness of the repo is by branch?  For example, branches from the non-Gerrit server will remain updated by that servers but the HA Gerrit will also have internal forks that does not exist on the non-Gerrit server.  Would this setup work?

Sure, but you need to ensure the branch updated in Gerrit is not also updated in the non-Gerrit

  It is definitely a split-brain at the repo level but perhaps not at the branch level?

Exactly.

HTH

Luca

Regards,

Kenny

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/2d8fed86-79a9-4370-8fb1-46365b6f23acn%40googlegroups.com.