Pagure Infrastructure SOP

Pagure is a code hosting and management site.

Contents

  1. Contact Information

  2. Description

  3. When unresponsive

  4. Git repo locations

  5. Services and what they do

Contact Information

Owner

Fedora Infrastructure Team

Contact

#fedora-apps

Location

OSUOSL

Servers

pagure01, pagure-stg01

Purpose

Source code and issue tracking

Description

Pagure ( https://pagure.io/pagure ) is a source code management and issue tracking application. Its written in flask. It uses: celery, redis, postgresql, and pygit2.

When unresponsive

Sometimes pagure will stop responding, even though it’s still running. You can issue a 'systemctl reload httpd' and that will usually get it running again.

Git repo locations

  • Main repos are in /srv/git/repositories/<projectname>

  • issue/ticket repos are under /srv/git/repositories/tickets/<projectname>

  • Docs are under /srv/git/repositories/docs/<projectname>

  • Releases (not a git repo) are under /var/www/releases/

Services and what they do

  • pagure service is the main flask application, it runs from httpd wsgi.

  • pagure_ci service talks to jenkins or other CI for testing PR’s

  • pagure_ev service talks to websockets and updates issues and comments live for users.

  • pagure_loadjson service takes issues loads from pagure-importer and processes them.

  • pagure_logcom service handles logging.

  • pagure_milter processes email actions.

  • pagure_webhook service processes webhooks to notify about changes.

  • pagure worker service updates git repos with changes.

Useful commands

This section lists commands that can be useful to fix issues encountered every once in a while.

  • Recompile the gitolite configuration file

    # sudo -u git HOME=/srv/git/ gitolite compile && sudo -u git HOME=/srv/git/ gitolite trigger POST_COMPILE

  • Duplicated projects

We have observed that every so often two different workers create a project in the database. This leads to pagure failing to give access to the project as it finds multiple projects with the same namespace/name where it expects these to be unique.

The following two SQL commands allows finding out which projects are in this situation:

:

select user_id, name, namespace, is_fork from projects where is_fork = FALSE group by namespace, name, is_fork, user_id having count(user_id) > 1;

select user_id, name, namespace, is_fork from projects where is_fork = TRUE group by namespace, name, is_fork, user_id having count(user_id) > 1;

This will return you the namespace/name as well as the user_id of the user who duplicated the projects in the database.

You can then do:

:

select id, user_id, name, namespace, is_fork from projects where name = '<the name of the project>' order by user_id;

In that query you will see the project id, user_id, name and namespace of the project. You will see in this one of the projects is listed twice with the same user_id (the one returned in the previous query).

From there, you will have to delete the duplicates (potentially the one with the highest project id).

If the project remains un-accessible, check the apache logs, it could be that the git repositories have not been created. In that case, the simplest course of action is to delete all the duplicates and let the users re-create the projects as they wish.