Added the infra SOPs ported to asciidoc.

modules/sysadmin_guide/pages/infra-repo.adoc

@@ -0,0 +1,113 @@
+= Infrastructure Yum Repo SOP
+
+In some cases RPM's in Fedora need to be rebuilt for the Infrastructure
+team to suit our needs. This repo is provided to the public (except for
+the RHEL RPMs). Rebuilds go into this repo which are stored on the
+netapp and shared via the proxy servers after being built on koji.
+
+For basic instructions, read the standard documentation on Fedora wiki:
+- https://fedoraproject.org/wiki/Using_the_Koji_build_system
+
+This document will only outline the differences between the "normal"
+repos and the infra repos.
+
+== Contents
+
+[arabic]
+. Contact Information
+. Building an RPM
+. Tagging an existing build
+. Promoting a staging build
+. Koji package list
+
+== Contact Information
+
+Owner::
+  Fedora Infrastructure Team
+Contact::
+  #fedora-admin
+Location::
+  PHX [53] https://kojipkgs.fedoraproject.org/repos-dist/
+Servers::
+  koji batcave01 / Proxy Servers
+Purpose::
+  Provides infrastructure repo for custom Fedora Infrastructure rebuilds
+
+== Building an RPM
+
+Building an RPM for Infrastructure is significantly easier then building
+an RPM for Fedora. Basically get your SRPM ready, then submit it to koji
+for building to the $repo-infra target. (e.g. epel7-infra).
+
+Example:
+
+....
+rpmbuild --define "dist .el7.infra" -bs test.spec
+koji build epel7-infra test-1.0-1.el7.infra.src.rpm
+....
+
+[NOTE]
+.Note
+====
+Remember to build it for every dist / arch you need to deploy it on.
+====
+
+After it has been built, you will see it's tagged as
+$repo-infra-candidate, this means that it is a candidate for being
+signed. The automatic signing system will pick it up and sign the
+package for you without any further intervention. You can track when
+this is done by checking the build info: when it is moved from
+$repo-infra-candidate to $repo-infra-stg, it has been signed. You can
+check this on the web interface (look under "Tags"), or via:
+
+....
+koji buildinfo test-1.0-1.el7.infra
+....
+
+After the build has been tagged into the $repo-infra-stg tag,
+tag2distrepo will automatically create a distrepo task, which will
+update the repository so that the package is available on staging hosts.
+After this time, you can yum clean all and then install the packages via
+yum install or yum update.
+
+== Tagging existing builds
+
+If you already have a real build and want to use it in the
+infrastructure before it has landed in stable, you can tag it into the
+respective infra-candidate tag. For example, if you have an epel7 build
+of test2-1.0-1.el7.infra, run:
+
+....
+koji tag epel7-infra-candidate test2-1.0-1.el7.infra
+....
+
+And then the same autosigning and repogen from the previous section
+applies.
+
+== Promoting a staging build
+
+After getting autosigned, builds will land in the respective infra-stg
+tag, for example epel7-infra-stg. These tags go into repos that are
+enabled on staging machines, but not on production. If you decide, after
+testing, that the build is good enough for production, you can promote
+it by running:
+
+....
+koji move epel7-infra-stg epel7-infra test2-1.0-1.el7.infra
+....
+
+== Koji package list
+
+If you try to build a package into the infra tags, and koji says
+something like: BuildError: package test not in list for tag
+epel7-infra-candidate That means that the package has not been added to
+the list for building in that particular tag. Either add the package to
+the respective Fedora/EPEL branches (this is the preferred method, since
+we should always aim to get everything packaged for Fedora/EPEL), or add
+the package to the listing for the respective tag.
+
+To add package to infra tag, run:
+
+....
+koji add-pkg $tag $package --owner=$user
+....