Running Kallithea on Windows

[Angel Ezquerra]

On Tue, Feb 9, 2016 at 6:51 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 02/09/2016 03:58 PM, Angel Ezquerra wrote:
>>
>> Hi,
>>
>> I am trying to setup Kallithea on a windows server and I have a few
>> questions. This email will be a bit long because I have many questions
>> and I'd like to give you some context first. If you want to just skip
>> to the questions you can find them below. But first, some context:
>>
>> - Our main motivation to use Kallithea (at this point) is to gain the
>> ability to perform code reviews on our code.
>>
>> - We also wonder if Kallithea might have better performance that the
>> existing "plain" mercurial server.
>
>
> I doubt it. It calls out to the same hgweb. But it is usually "fast enough".
> If not, it is probably a configuration / setup / architecture issue.
>
>> Our current setup is as follows:
>> - We have an Apache-based (WSGI) mercurial server, running on a
>> Windows Server machine.
>>      - The mercurial server is a "plain" mercurial server that we have
>> customized a bit:
>>          - We have added a header to every mercurial server web page,
>> containing links to our issue tracker and to our customized TortoiseHg
>> (we use the web.MOTD setting to do this).
>>          - The header also has a link to open a dialog to  create a
>> repository and also to create a "link" (an NTFS junction) to an
>> existing repository
>>
>> - We have over 1.500 mercurial repositories, organized in multiple
>> directories (and directories within directories, etc). To give you an
>> idea, the root contains 27 directories (corresponding to several
>> groups, projects, etc)
>>      - Some of the repos are pretty big (hundreds of megabytes) as they
>> contain binary files (I have no control over this, unfortunately).
>>      - May of our repositories contain subrepos.
>
> How are they organized? Are you stuck with some hardcoded URLs?

No, we never use hardcoded URLs AFAIK. We follow the recommended
practice of only using simple, relative subrepository references (i.e.
such as my/subrepo/path = my/subrepo/path). If someone is not doing
that they would have to fix it.

>>      - In order to avoid duplication and to share the same components
>> among multiple projects we often create "repository links", which are
>> NTFS junctions (akin to Unix soft links)
>
>
> Why do the same repository have to appear in multiple places? (Perhaps
> related to the previous question?)

We have "platform" teams that create common modules that are reused
(as dependencies) by multiple "technology teams". Those common modules
are usually included in the technology team projects as subrepos. In
order to avoid the need to manually keep the "copies"of the platform
module repositories in sync on each technology project we decided to
use NTFS junctions on the server. This ensures that every project that
uses a given common, platform module will see every new changes that
is pushed to that platform module, without the need of any manual
sync. This works really, really well (we've been doing this for
several years now, without any issues).

>>      - We found that with that many repositories it is not practical to
>> use mercurial's "recursive path" definitions (i.e. using "**") to let
>> the server find the repos. It is just way too slow. That is why
>> instead we keep a list of every repository on our server, which is
>> automatically updated when someone creates a new repository or link
>> through our custom dialogs, and also by a script that runs every 15
>> minutes (in case an admin creates a repository manually)
>
> Will you use Kallithea for creating repos?

Not at first. As I said our plan is to use Kallithea as a review
server _initially_. However my hope is that at some point we will
migrate to Kallithea and abandon the vanilla mercurial server that we
are currently using.

>> So now the questions:
>>
>> 1. Is it possible to configure Kallithea as a "code review" only tool,
>> disabling both push and, above all, pull access?
>
> If you want to that as 'configuration' only, I would do it by configuring
> filter in the web server.

I don't understand what you mean. Could you please elaborate, please?

> I would probably prefer to have a local code customization that disable
> protocol access.

I'm not sure what you mean here either. Do you mean that you'd like to
have some way to configure Kallithea as a code review only told from
the Kallithea UI, but that it is not currently possible to do so?

>> 2. How well does Kallithea support subrepos? It seems that Kallithea
>> does not find subrepos when it scans for repositories, but maybe I
>> missed something...
>
> There is a small snippet on
> http://kallithea.readthedocs.org/en/latest/usage/vcs_support.html#working-with-mercurial-subrepositories
> - but it doesn't say much.

No, it does not say much. Is it true that Kallithea will not show
subrepos on the repository list?

> I think 'server structure matches working directory structure' is
> problematic. There is the inherent problem that URLs become ambiguous when
> using that scheme. That ambiguity has to be resolved somewhere. Something
> could perhaps be implemented in Kallithea ... but I guess it would be better
> to do it elsewhere (web server configuration or client side).

Are you referring to the fact that subrepos are stored on the
repository working directory? If so I cannot agree more, and I have
been planning to fix that at the mercurial level for years now. I have
done some work towards that end (even on the last mercurial sprint in
London) but I am still quite far from reaching that goal.

In the mean time I think the best we could do would be for Kallithea
to deep scan the repositories it finds looking for subrepos, and show
them with every other regular repository. This is what hgweb does.

Related, is there a way to programatically ask Kallithea to add a
particular repository path to its repository list? Is it possible to
programatically trigger the repository scan of a particular folder?

>> 3. How well would Kallithea coexist with our existing mercurial server
>> if they both pointed to the same repositories? That is, if we
>> configure Kallithea to look for repositories on the same location that
>> the existing mercurial server looks for them, would there be any
>> problems? In theory mercurial creates locks to avoid problems with
>> concurrent repository access. Should this work?
>>      - The reason I wonder this is that, at least for now, I'd rather
>> not replace our server with Kallithea, but add it as an alternative
>> interface. This would give people some time to tray it and give me
>> feedback.
>
> I don't know 'mercurial server' (and I hate the name for being so
> misleading).

When I say "mercurial server" I mean our hgweb instance that is served
by apache.

> Repo write operations still use the same lock as hgweb ... but you don't
> want write anyway?

Not for now but at some point we might. I reckon that this would not
be a problem since Kallithea uses hgweb?

> Kallithea uses another way of repo cache invalidation than hgweb. You can
> call something like
> paster update-repoinfo /srv/kallithea/kallithea.ini --invalidate-cache
> --update-only=$repopath
> from a hgweb push hook.

Do you mean that if Kallithea is "observing" and existing repository
that is being modified by pushes through an hgweb instance, we would
need to somehow trigger a cache invalidation manually through a push
hook on the hgweb instance? What would that be necessary?

>> 4. Is there a way to configure the Kallithea interface, other than
>> manually modifying the HTML templates? In particular, is there a way
>> to add some sort of banner to every page server by Kallithea (to add
>> links to our issue tracker, our TortoiseHg installer, and so on)?
>>      - Also, is there a way to "brand" our server (e.g. adding our
>> company logo, changing the colors to our corporate colors, etc?)
>
> There is the 'bugtracker' setting in the .ini file. There is also site
> branching in .../_admin/settings/global . Beyond that, you currently have
> the full freedom to hack the code ;-)

:-)

The thing that worries me is what would happen if we manually modified
some of the html templates and then used pip to update to a newer
Kallithea version... That is why we used web.MOTD to add our banner,
rather than modifying an existing hgweb template (we could have
created a new one, but I was lazy at the time :-P).

>> 5. How fast can we expect Kallithea to be with our environment (in
>> particular with the number of repositories that we have)?
>>      - Should we expect the "raw  Kallithea" server to perform well or
>> should we investigate integrating it with our Apache server, or
>> perhaps using some other server (ISS, etc)?
>
> What do you mean with "raw Kallithea"? The development standalone web
> server?

I meant Kallithea when run directly, without using apache or IIS or similar.

> I would use a real web server - mostly to get easy management and a full
> featured web server and a simple setup. I prefer mod_wsgi.
>
> No matter what: For bulk operations it calls out to the same Python
> mercurial stuff as hgweb and it will perform pretty much the same. Python is
> probably the bottleneck but still "fast enough" to saturate a Gbit
> connection on a normal server. Using a 'high performance' web server will
> probably not buy you anything.

What about having people pulling / pushing from the same or different
repos in parallel (when / if we end up replacing our hgweb instance
with Kallithea at some point)?

>> 6. How is the code review information stored by Kallithea?
>>      - Can be exported somehow? Can it be copied into a new Kallithea
>> server?
>
> It is stored in the database. You can get it with sql or other tools. I
> don't know what format you would want it in and I am not aware of any tools
> for any other format than sql dump.

I'm basically worried of the possibility of having to move to a
different server at some point. Would it be possible to just copy the
Kallithea database to the new server?
Also, it would be nice to have a way to dump the review comments to a
CSV somehow.

>> 7. What would be the best way to run Kallithea as a service on
>> Windows? There might be some page that explains this. If so just let
>> me know.
>
> I assume you have browsed through the documentation and have seen the
> documentation of using Apache (the documentation assumes unix but I guess it
> is pretty much the same on windows) and IIS.
>
> People with experience from running on Windows can probably share opinions
> and experience.

I'll dig a bit more but suggestions are welcome, particularly if they
are related to Apache, as that is what we currently use for hgweb.

> I hope this helps - and that you can help improving our documentation so it
> would have answered any questions I might have given a sufficiently good
> answer to here ;-)

Yes, it definitely does help!

I must say that today I showed my local instance of Kallithea to my
team and they were very impressed! At this point I think our biggest
urdle will be having a way to automatically add our subrepos to the
Kallithea repository list.

One comment I got was that it would be nice if Kallithea recorded who
last moved a revision "review state" and showed that info on the
changelog (at least on a tooltip that were shown when the mouse is put
on top of the colored review circle icon).

Cheers,

Angel