Kallithea issues archive

http://kallithea.readthedocs.org/en/latest/usage/performance.html says

"each instance needs it’s own .ini file and unique instance_id set in them"

to me that sounds like you can't use uwsgi with multiple processes

So Kallithea doesn't notice the repo changed after someone pushed. There is a "install git hook" option under admin. Have you used that?

Re instance_id: It can be set to '*' to assign it randomly. That do however mean that you should run paster cache-keys my.ini --cleanup regularly to avoid filling up the database.

I have refactored this instance-id system so I kind of understand what it is doing. I'm quite sure it pretty much just can be removed and replaced with something simpler.

@domruf I switched to using 1 process and at least so far that appears to have solved the problem. There was no real reason for 4 processes, other than example uwsgi configuration files I was using did that (though for other applications).

Any idea why this would have only affected git and not Mercurial repos?

@kiilerix is the expert here :-)

/me repeats question: There is a "install git hook" option under admin. Have you used that?

The option under "Remap and rescan"? If I check that and rescan, all I see is

Repositories successfully rescanned added: - ; removed: - 

Again, no useful output in the server log. I'm also not completely clear on what this is supposed to be doing in the first place.

There should be hooks in place to update/expire Kallithea caches. Mercurial hooks pretty much just works. Git hooks are more tricky. Some digging around kallithea/lib/hooks.py might help figuring out what is going on.

The hook should pretty much do the same as paster update-repoinfo my.ini --update-only=my/repo --invalidate-cache you can perhaps try running it manually.

Does the same thing happen for git repos created from Kallithea and for 'scanned' repos?

digging around kallithea/lib/hooks.py might help figuring out what is going on.

Thanks for the pointer. I'll look into it a bit more later this week.

Does the same thing happen for git repos created from Kallithea and for 'scanned' repos?

I only have Kallithea-created git repos at the moment.

Did you figure out exactly what was and wasn't the issue here?

Other than switching to use 1 process with uwsgi, no. Looking at the handle_git_receive function in kallithea/lib/hooks.py indicates that it executes a subprocess to do what it does, so that probably has something to do with it. This looks to be happening on lines 451, 457, and 465 with calls to repo.run_git_command. It would probably make more sense to use something like dulwich to read the repository rather than spawning subprocesses to run git commands.

Sure, pure dulwich would be better ... if it can do it. I assume there is a reason it is the way it is.

But I doubt the callout to git is related to your issue.

How is your instance_id configured?

I don't have instance_id set in the ini file.

The ini file template and http://kallithea.readthedocs.org/en/latest/usage/performance.html says that it must be set uniquely if you run multiple instances - as you do. What you see is pretty much what you can expect with the configuration you have. Not a bug but incorrect configuration.

The documentation could however be improved ... and we could reimplement this part of the system so it was less annoying. Contributions would be appreciated.