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

[Mads Kiilerich]

On 04/21/2015 10:19 AM, Thomas De Schampheleire wrote:
> On Tue, Apr 21, 2015 at 3:21 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> 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.
>>
> What you mean here is that Kallithea is not yet fit for this model?

Not really. I mean that there is a lot of things to consider and test 
with your latency and bandwidth and workload.

/Mads