-
Notifications
You must be signed in to change notification settings - Fork 89
Packaging
This page explains how to produce packages from the source tree.
Timestamps are in UTC time-zone, in the format YYYYMMDDhhmm as outputted by date -u +%Y%m%d%H%M.
There are four different types of packages created publicly available (Sample package names for all components are provided below, for both RHEL and DEB).
CI Builds (unpublished): Right now NOT PUBLICLY AVAILABLE ! Generated code that is actively being worked on. Packages with version number based on git describe --tags, replacing '-' with '.'. Or based on the bare git SHA preceded by a timestamp (if branching scheme makes git-describe output non-informative), this is the result of running git rev-parse --short HEAD.
Unstable: Generated on a daily basis from code that is actively being worked on. These packages are generated from the master branch. They are uploaded to the unstable package repository.
Testing: Generated from code that is frozen and getting prepared for release. These packages are generated from the staging/* branch. They are uploaded to the testing package repository.
Stable: Generated from code that has successfully passed the QA phase and released. These packages are generated from the stable/* branch. They are uploaded to the stable package repository.
Hotfix: Generated to address a mission-critical issue found found in a released version without waiting for a patch release that would require a full QA cycle. They are generated from a hotfix branch created off of the stable/* branch. They are uploaded to the stable package repository.
| Type of releases | RPM | deb |
|---|---|---|
| Build # (unpublished) | midolman-YYYY.MM-0.0..[.el6|el7].noarch.rpm | midolman_YYYY.MM~._all.deb |
| Unstable | midolman-YYYY.MM-0.0..[.el6|el7].noarch.rpm | midolman_YYYY.MM~._all.deb |
| Testing | midolman-YYYY.MM-0.1.rc0[.el6|.el7].noarch.rpm | midolman_YYYY.MM~rc0_all.deb |
| Stable | midolman-YYYY.MM(.Z)-1.0[.el6|.el7].noarch.rpm | midolman_YYYY.MM(.Z)_all.deb |
| Hotfix | midolman-YYYY.MM(.Z)-1.0.hf1[.el6|.el7].noarch.rpm | midolman_YYYY.MM(.Z).hf1_all.deb |
| Type of releases | RPM | deb |
|---|---|---|
| Build # (unpublished) | midonet-api-YYYY.MM-0.0..[.el6|el7].noarch.rpm | midonet-api_YYYY.MM~._all.deb |
| Unstable | midonet-api-YYYY.MM-0.0-.[.el6|el7].noarch.rpm | midonet-api_YYYY.MM~._all.deb |
| Testing | midonet-api-YYYY.MM-0.1.rc0[.el6|.el7].noarch.rpm | midonet-api_YYYY.MM~rc0_all.deb |
| Stable | midonet-api-YYYY.MM(.Z)-1.0[.el6|.el7].noarch.rpm | midonet-api_YYYY.MM(.Z)_all.deb |
| Hotfix | midonet-api-YYYY.MM(.Z)-1.0.hf1-[.el6|.el7].noarch.rpm | midonet-api_YYYY.MM(.Z).hf1_all.deb |
(TODO: Only one section for all packages generation!) This section explains different ways to generate packages.
Run the following commands from source on the appropriate branch to generate both midolman and midonet-api packages:
- Debian:
gradle clean debian -x test - RHEL6:
gradle clean rpm -x test - RHEL7:
gradle clean rpm -PrhelTarget=7 -x test
If you want to deliver a package for release, it needs to be signed. You can achieve this by generating packages from Jenkins on-demand jobs, which sends the generated package for each distro to the package signing server automatically. These jobs allow a "Build with Parameters" that will require:
- Git revision: use the SHA that you tagged (TODO: automate this, it wasn't working in the old Jenkins version but this problem should be gone now)
- Publish checkbox: mark it to have packages sent to the signing machine, otherwise they will remain stored temporarily in the Jenkins instance.
- Modify the job description with details about the packages.
- TODO: automate picking up new tags and building
From the top of the source tree, run the following command to generate both rpm and deb packages:
./package.sh
For example, package files would look like the following:
| Type of releases | RPM | deb |
|---|---|---|
| Build # (unpublished) | python-midonetclient-YYYY.MM-0...noarch.rpm | python-midonetclient_YYYY.MM~._all.deb |
| Unstable | python-midonetclient-YYYY.MM-0...noarch.rpm | python-midonetclient_YYYY.MM~._all.deb |
| Testing | python-midonetclient-YYYY.MM-0.rc0.noarch.rpm | python-midonetclient_YYYY.MM~rc0_all.deb |
| Stable | python-midonetclient-YYYY.MM-1.noarch.rpm | python-midonetclient_YYYY.MM_all.deb |
Neutron MidoNet Plugin (aka networking-midonet) uses a different branching, package name schema from MidoNet, because it has to fit into OpenStack's releases.
Following the guides, they strongly recommend to name the package after the
upstream source code. Since the source code has needed to change to
networking-midonet due StackForge naming conventions, the package should be named python-networking-midonet since Kilo.
We propose to use the same naming as OpenStack, using the third number as plugin's bugfix release. Version tag has 3 sections:
XXXX.N.P
Where:
- XXXX.N is the Neutron's version release naming value which the plugin is compatible with.
- P is the 'plugin's' patch release.
noarch for Fedora and all for Debian. That's all. This package is architecture independent.
We will support rpm, deb and source tarballs.
We discuss here the minimal details that could make differences between three
supported packaging formats: tarball, rpm and deb.
Pypi accepted version number is based on PEP440 specification. In short: no letters, no release numbers and only some devX values for pre releases and postX for post-releases.
Of course, as a difference to other packaging systems, naming conventions does not force us to add the python suffix.
So we plan to upload to pypi only when there are new releases of our plugin. Tarball format is:
networking-midonet-XXXX.N.P.tar.gz
For rpm packages we have based on the Fedora's Packaging Guidelines.
The release tag will be:
- 0.0. for nightly builds
-
0.1.rc%{Y} for release candidates. the words
rcshould always have more precedence that any snapshot in packaging managers, so the 0.0 and 0.1 release value may not be necessary, but we'd like to keep it to maintain consistency with MidoNet's naming conventions. %{Y} is the rc value. - 1 for new releases.
Release tag will be inserted by the packaging system jobs (such as Jenkins, Koji or whatever)
All the packages will be built over they target architecture. No fpm any more. Jenkins jobs will provide the Docker containers to build those packages.
According to Fedora's documentation:
%{checkout} consists of the date that the snapshot is made in YYYYMMDD
format, a short (2-5 characters) string identifying the type of revision
control system or that this is a snapshot, and optionally, up to 13
characters (ASCII) alphanumeric characters that could be useful in finding
the revision in the revision control system
showing these examples:
20110102snap
20110102git
20110102git9e88d7e
I would propose the third one, which makes the difference between two packages that are build the same day.
Fedora allows a, b, alpha, beta or rc as non-numeric values in pre-releases. We will only use the rc ones in packaging.
I would not use post-release packages: we have already the minor release number in our version to indicate bug fixes over a released versions.
For deb package we have based on the How to package for Debian site.
Debian packaging follows the same format:
[epoch:]upstream_version[-debian_revision]
Where neither epoch and +debian_revision are mandatory. We don't need to
define an epoch and, according to the documentation, the debian_revison:
It is optional; if it isn't present then the upstream_version may not
contain a hyphen. This format represents the case where a piece of software
was written specifically to be a Debian package, where the Debian package
source must always be identical to the pristine source and therefore no
revision indication is required.
We will use the same source code, so debian_revision is not needed too. When
it comes to upstream_version sort order:
First the initial part of each string consisting entirely of non-digit
characters is determined. These two parts (one of which may be empty) are
compared lexically. If a difference is found it is returned. The lexical
comparison is a comparison of ASCII values modified so that all the letters
sort earlier than all the non-letters and so that a tilde sorts before
anything, even the end of a part.
So we will leverage the tilde (~) to define the snapshots and any rc value
will be ordered before any number.
Debian does not specify any snapshot value, so we will use the same one as Fedora but with the tilde: ~YYYYMMDDgit like this
~20110102git9e88d7e
Again, there is no format definition for pre-releases. Using rc like Fedora and knowing that they will be sorted after any ~ snapshot will guarantee us coherency.
No post-release definition and no need for it.
| Type of releases | RPM | deb |
|---|---|---|
| snapshot | python-networking-midonet-2015.1.0-0.0.20150434git238ab24.noarch.rpm | python-networking-midonet-2015.1.0~20150434git238ab24_all.deb |
| rc release | python-networking-midonet-2015.1.2-0.1.rc4.noarch.rpm | python-networking-midonet-2015.1.2~rc4_all.deb |
| release | python-networking-midonet-2015.2.1-1.noarch.rpm | python-networking-midonet-2015.2.1_all.rpm |
Run the script packaging/rpm/packaging_rpm.sh in RedHat/CentOs or the script packaging/deb/packaging_deb in networking-midonet source code to generate the package.