Added the infra SOPs ported to asciidoc.

modules/sysadmin_guide/pages/pagure.adoc

@@ -0,0 +1,114 @@
+= Pagure Infrastructure SOP
+
+Pagure is a code hosting and management site.
+
+== Contents
+
+[arabic]
+. Contact Information
+. Description
+. When unresponsive
+. Git repo locations
+. 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.