[PATCH] pullrequests: add support for custom pull request id prefix

[Mads Kiilerich]

On 04/21/2015 06:20 AM, Thomas De Schampheleire wrote:
> On Mon, Apr 20, 2015 at 11:35 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
>>
>>>> It is a bit weird that Kallithea pull request numbers are global.
>>>> Especially
>>>> in a site that is hosting repos for multiple independent users, it would
>>>> make sense to have per repo numbering. Would that solve your case? Will
>>>> your
>>>> repos in the different instances be named differently?
>>> No, the different instances would operate on the same repositories
>>> with the same names (note that we're not using Kallithea for repo
>>> hosting, it is a mirror).
>>
>> Using it as a mirror is fine ... but having multiple independent instances
>> does not seem like something I can recommend. It would make more sense to
>> have multiple servers on the same database in some failover loadbalancing
>> setup.
> The reason we planned doing such a setup is that the network
> latency/bandwidth between sites is not always very good. If there is
> one single Kallithea instance in a given site, the developers from
> that site get a good experience, while the developers from a remote
> site may suffer high latencies. With a local database + instance this
> would be mitigated.

We have local mirrors for the actual cloning - using 
https://bitbucket.org/Unity-Technologies/hgwebcachingproxy/commits/all 
and 
https://bitbucket.org/Unity-Technologies/dynapath/commits/branch/default .

Are you sure you need locally hosted Kallithea instances for the web UI? 
Depending on the size of your changes and your workflow, the 
requirements for bandwidth and latency might not be that high. 
Especially not to justify the added complexity for users and admins for 
managing multiple instances.

> Your suggestion of the same database and multiple Kallithea instances:
> how exactly does this work? Is all locking in place? And since the
> database is in one place: don't you suffer from the same network
> latency issue?

The database could perhaps be distributed, with one master for writing 
and local mirrors for reading. The database access pattern might however 
not be good for that; read only operations have too many writes.

/Mads