Getting Packages To Users
One of the Paas SIG goals is to get working OpenShift Origin packages to users. Our official way of getting the packages to users is via yum repositories. The general steps are outlined in the Release Workflow.
But the workflow page doesn't cover some of the behind the scenes work that has to happen for certain steps to be able to work. That is what this page is for. It's possible that these two pages can be combined into one larger page.
Contents
1. Setup For Each Major Release
Each Origin Major release gets its own CentOS build target, set of tags, and set of repositories. We originally had them all in one large repository, but it soon was obvious that this didn't work for the overlapping installation style that OpenShift Origin uses.
1.1. Targets and Tags
To create a new batch of tags and build targets, you need to create an issue in the CentOS Bug Tracker.
- What is needed in the request:
Category: "community buildsys"
Description: List of tags that you want created
Example: paas7-openshift-origin310-{candidate,el7-build,release,testing}
Description: Tell them that you want the target setup similar to the last origin targets.
1.2. Testing Repo
When you start getting packages built, and ready for testing, you need to request a testing repository. Since this takes a little bit of time to setup, you might want to plan for this early. You can tag your general packages into -testing first, such as python-keyczar, and then request the -testing repo early. That way, when you get your origin package built, the -testing repository will be ready.
Once a testing repository is created, you can just tag packages into it, and they will show up in 20 to 120 minutes.
To create a new testing repository, you need to create an issue in the CentOS Bug Tracker.
- What is needed in the request:
Category: "community buildsys"
Description: What tag goes into the repo (Can be more than one but we don't usually do that)
Example: paas7-openshift-origin39-testing
Description: Where in the tesing repo this should go
Description: A line for the CentOS maintainers. This makes things go faster. Just change our example from origin39 to whatever you need.
- + paas7-openshift-origin39-testing /|7/paas/x86_64/openshift-origin39/|7/paas/x86_64/openshift-origin39/|7/paas/x86_64/openshift-origin39/
1.3. Released Repo
Just like the testing repositories, you need to request released repositories. Unlike testing repo's, you do not want to do this early. Only request these repositories when you are ready for a release. Otherwise people are going to think your version of origin is released and start filing bugs that you are missing packages.
Once a released repository is created, you can tag packages into it. Signed packages will show up every day (from Monday to Thursday) at 09:00am UTC.
To create a new release repository, you need to create an issue in the CentOS Bug Tracker.
- What is needed in the request:
Category: "community buildsys"
Description: What tag goes into the repo (Can be more than one but we don't usually do that)
Example: paas7-openshift-origin39-testing
Description: Where in the tesing repo this should go
Description: A line for the CentOS maintainers. This makes things go faster. Just change our example from origin39 to whatever you need.
- + paas7-openshift-origin39-testing /|7/paas/x86_64/openshift-origin39/|7/paas/x86_64/openshift-origin39/|7/paas/x86_64/openshift-origin39/
Note:
- for 3.10 release repo i had to first tag the origin package, wait till it was added through Koji repos (mash job) and then CentOS infra team was able to proceed.
the mash job role is to compose the unsigned repositories - ie like this
1.4. Release RPMS
In order for users to easily use the Released Repo's, they need to install the corresponding centos-release-openshift-origin3* rpm. This package is in the main centos-extras repository, so it is easy to install. This package contains the yum configuration files so users can use our Released Repos. CentOS Documentation on Release Packages
These packages can be created ahead of time, and even in batches. If you make the packages ahead of time, do not tag them into the -release tag until you released the corresponding origin version and have created the Released Repo for it.
To create a new centos-release-openshift-origin3* rpm, you need to first add the package to the tag. For our examples we will be making a release package for origin 3.10
cbs add-pkg --owner=rmartinelli core7-extras-common-candidate centos-release-openshift-origin310
cbs add-pkg --owner=rmartinelli core7-extras-common-testing centos-release-openshift-origin310
cbs add-pkg --owner=rmartinelli core7-extras-common-release centos-release-openshift-origin310
Then you need to create the new source rpm, and build it on cbs.
Download the previous versions source rpm from cbs
- unpack the source rpm and edit the spec file
rpm -Uvh centos-release-openshift-origin39-1-1.el7.centos.src.rpm
mv ~/rpmbuild/SPECS/centos-release-openshift-origin39.spec ~/rpmbuild/SPECS/centos-release-openshift-origin310.spec
vi ~/rpmbuild/SPECS/centos-release-openshift-origin310.spec
- Change all the 3.9 and 39 to 3.10 and 310
- Build the new source rpm
rpmbuild -bs --nodeps --define 'dist .el7.centos' ~/rpmbuild/SPECS/centos-release-openshift-origin310.spec
- It should tell you where the new source rpms is
- Build the package on cbs
cbs build core7-extras-common-el7.centos ~/rpmbuild/SRPMS/centos-release-openshift-origin310-1-1.el7.centos.src.rpm
Finally, when it's time for a release, tag your cbs built package into the extras release repo.
cbs tag-build core7-extras-common-release centos-release-openshift-origin310-1-1.el7.centos
Once all the above was achieved, reach out to Johnny Hughes (irc nickname hughesjr) on centos-devel irc channel and ask him to build/sign/push the rpm. You should also mention to him the rpm arch - currently only x86_64 is supported.
2. Tagging
To look at targets, and work with tags, you much have cbs installed. If you do not, here are the instructions for installing cbs
Very good explanation on Tags and Targets
2.1. CBS commands
- To list all cbs commands
cbs help
- To know the syntax of a command
cbs <command> --help
example: cbs list-tagged --help
- To list all tags in the Paas SIG
cbs list-tags | grep paas7
- To list all targets in the Paas SIG
cbs list-targets | grep paas7
- To see what packages are tagged into a tag
cbs list-tagged <tag>
example: cbs list-tagged --latest paas7-openshift-origin39-candidate
example: cbs latest-build --all paas7-openshift-origin39-candidate
- To tag a package
cbs tag-build <tag> <NameVersionRelease>
example: cbs tag-build paas7-openshift-origin39-candidate golang-1.9.2-4.el7
- To untag a package
cbs untag-build <tag> <NameVersionRelease>
example: cbs untag-build paas7-openshift-origin39-candidate golang-1.9.4-1.el7
Note: This does not automatically remove packages from repos. You have to open a bug/issue for that.
2.2. Candidate Repo
Packages that are tagged into -candidate is what the corresponding target builds with. So if you need to build with a specific version of golang, tag it into the the -candidate repo it needs to be in. Also, packages that are built with the corresponding target get a -candidate tag. It usually takes 10-20 minutes for a package to make it into a repo.
cbs tag-build <tag> <NameVersionRelease>
example: cbs tag-build paas7-openshift-origin39-candidate golang-1.9.2-4.el7
2.3. Testing Repo
Packages that are tagged into -testing go into the corresponding testing repo (if it has been created. See above). It usually takes between 20 minutes and 2 hours for a package to make it into the repo.
cbs tag-build <tag> <NameVersionRelease>
example: cbs tag-build paas7-openshift-origin39-testing origin-3.9.0-1.el7.git.0.ba7faec
2.4. Released Repo
Packages that are tagged into -release go into the corresponding released repo on the mirrors (if it has been created. See above). The signing and pushing process usually only happens once a day, Monday through Thursday.
cbs tag-build <tag> <NameVersionRelease>
example: cbs tag-build paas7-openshift-origin39-release origin-3.9.0-1.el7.git.0.ba7faec