On Tue, Apr 21, 2015 at 4:37 PM, Mads Kiilerich <[email protected]> wrote: > On 04/21/2015 10:19 AM, Thomas De Schampheleire wrote: >> >> On Tue, Apr 21, 2015 at 3:21 PM, Mads Kiilerich <[email protected]> >> wrote: >>> >>> On 04/21/2015 06:20 AM, Thomas De Schampheleire wrote: >>>> >>>> On Mon, Apr 20, 2015 at 11:35 PM, Mads Kiilerich <[email protected]> >>>> 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. >
Let me restate my question: does Kallithea fully support having one database with multiple frontends? Second question is: how do you suggest testing this? Do you mean just clicking about, pulling/pushing, creating pull requests etc. to see how responsive things are? Or is there a more objective way to test things? Thanks, Thomas _______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
