Major docs update
[integration/packaging.git] / docs / rpms.rst
1 RPMs
2 ====
3
4 OpenDaylight has a mature RPM Continuous Delivery pipeline. Every autorelease
5 build is automatically packaged as an RPM, and even if autorelease is broken
6 a daily job builds the latest distribution snapshot build into an RPM.
7
8 RPMs can be passed to test jobs that install them, start OpenDaylight with it's
9 systemd service, connect to the Karaf shell and verify basic functionality.
10
11 RPMs are hosted on the CentOS Community Build system repositories. Some repos
12 are updated very frequently with the latest builds, while others are permeate
13 homes of official releases.
14
15 Developers can build custom RPMs with pre-merge patches for testing by first
16 creating a custom distribution with the integration-multipatch-test job and
17 then feeding the resulting artifact to the packaging-build-rpm job.
18
19 Build Jobs
20 ----------
21
22 OpenDaylight Integration/Packaging has added support for many variations of
23 fully automated RPM builds.
24
25 packaging-build-rpm
26 ^^^^^^^^^^^^^^^^^^^
27
28 The `packaging-build-rpm job`_ is the primary way to build an RPM from an
29 OpenDaylight distribution (built by autorelease or the snapshot distribution
30 job). It accepts a set of `parameters`_ that can be used to configure the build
31 and passes them to the `RPM build logic in Integration/Packaging's repo`_. The
32 resulting artifacts are hosted on Jenkins for up to a week. The job actually
33 produces both a noarch RPM and source RPM. The noarch RPM can be passed to test
34 jobs for validation. The source RPM can be downloaded to a system with the
35 required credentials and then pushed to the CentOS Community Build system to
36 be built into a noarch RPM on their servers and hosted in their repos.
37
38 packaging-build-rpm-snap
39 ^^^^^^^^^^^^^^^^^^^^^^^^
40
41 The `packaging-build-rpm-snap job`_ packages the most recent snapshot
42 distribution build from a given branch as an RPM. This could be used by a
43 developer to test code that was just merged, but which has not been included
44 in an autorelease build yet. The job is also triggered daily, to ensure that
45 OpenDaylight's Continuous Delivery pipeline is fed new builds even if
46 autorelease is broken.
47
48 Test Jobs
49 ---------
50
51 packaging-test-rpm
52 ^^^^^^^^^^^^^^^^^^
53
54 The `packaging-test-rpm job`_ accepts a link to an RPM and validates it. It
55 installs the package with the system's package manager, starts OpenDaylight's
56 systemd service, verifies that it's reported as active, connects to the Karaf
57 shell and checks that some key bundles are present.
58
59 Repositories
60 ------------
61
62 CentOS
63 ^^^^^^
64
65 While most RPM builds are triggered automatically in OpenDaylight's Jenkins,
66 some RPMs are promoted to be hosted in OpenDaylight's CentOS repositories.
67 There are a series of repos that are updated at varying frequencies, from
68 testing repos that are updated with pre-release versions very frequently to
69 release repos that are the permeate home of official OpenDaylight releases.
70
71 Testing Repositories
72 ....................
73
74 Repositories with the -testing suffix are updated very frequently with
75 pre-release versions of OpenDaylight from the appropriate branch. New RPMs
76 replace the old ones, so installing from these repos will always provide the
77 most recent versions.
78
79 Testing repos for Boron, Carbon and Nitrogen:
80
81 - `nfv7-opendaylight-5-testing`_
82 - `nfv7-opendaylight-6-testing`_
83 - `nfv7-opendaylight-7-testing`_
84
85 Release Repositories
86 ....................
87
88 Repositories with the -release suffix host official OpenDaylight releases. They
89 are updated infrequently to never, and will host their release artifacts
90 forever. Release repos are subdivided into two groups based version numbers.
91 Repositories with both a major and minor version number (52, 53, 60) are pinned
92 to a specific OpenDaylight release or service release (Boron SR2 5.2.0, Boron
93 SR3 5.3.0, Carbon 6.0.0). Repositories with only a major version (5, 6) will
94 always host the latest service release from that major release. If a new SR
95 come out, the repo will get the update (Boron SR4 will replace Boron SR3).
96
97 Release repos for the latest Boron and Carbon service releases:
98
99 - `nfv7-opendaylight-5-release`_
100 - `nfv7-opendaylight-6-release`_
101
102 Release repos that will permanently host specific Boron and Carbon releases:
103
104 - `nfv7-opendaylight-50-release`_
105 - `nfv7-opendaylight-51-release`_
106 - `nfv7-opendaylight-52-release`_
107 - `nfv7-opendaylight-53-release`_
108 - `nfv7-opendaylight-60-release`_
109
110 Repository Configuration Files
111 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
112
113 While it's possible to install RPMs directly (`dnf install -y <URL>`), it's
114 often easier to use a repository configuration file to install whatever the
115 latest RPM is in a given repo.
116
117 The OpenDaylight Integration/Packaging project provides `example repo config
118 files for each official repository`_.
119
120 Package managers like Yum and DNF will automatically find repo configuration
121 files placed in the /etc/yum.repos.d/ directory. Curl them into place with
122 something like:
123
124     sudo curl -o /etc/yum.repos.d/opendaylight-7-testing.repo \
125       "https://git.opendaylight.org/gerrit/gitweb?p=integration/packaging.git;a=blob_plain;f=rpm/example_repo_configs/opendaylight-7-testing.repo"
126
127 Standard install commands will now find the repository as expected.
128
129     sudo dnf install -y opendaylight
130
131 Custom RPMs
132 -----------
133
134 It's possible for developers to build custom RPMs, typically with unmerged
135 patches that need system testing. First, use the integration-multipatch-test
136 job to create a custom distribution that includes the set of unmerged patches.
137 See the `Custom Distributions <distribution-job-builds.rst#Custom
138 Distributions>`_ section for extensive docs. Once you have a custom
139 distribution artifact, pass it to the `packaging-build-rpm job`_ to package it
140 as an RPM. See the `packaging-build-rpm`_ section for docs.
141
142 .. _packaging-build-rpm job: https://jenkins.opendaylight.org/releng/job/packaging-build-rpm-master/
143 .. _parameters: https://jenkins.opendaylight.org/releng/job/packaging-build-rpm-master/build
144 .. _RPM build logic in Integration/Packaging's repo: https://github.com/opendaylight/integration-packaging/blob/master/rpm/build.py
145 .. _packaging-build-rpm-snap job: https://jenkins.opendaylight.org/releng/job/packaging-build-rpm-snap-master/
146 .. _packaging-test-rpm job: https://jenkins.opendaylight.org/releng/job/packaging-test-rpm-master/
147 .. _nfv7-opendaylight-5-testing: http://cbs.centos.org/repos/nfv7-opendaylight-5-testing/x86_64/os/Packages/
148 .. _nfv7-opendaylight-6-testing: http://cbs.centos.org/repos/nfv7-opendaylight-6-testing/x86_64/os/Packages/
149 .. _nfv7-opendaylight-7-testing: http://cbs.centos.org/repos/nfv7-opendaylight-7-testing/x86_64/os/Packages/
150 .. _nfv7-opendaylight-5-release: http://cbs.centos.org/repos/nfv7-opendaylight-5-release/x86_64/os/Packages/
151 .. _nfv7-opendaylight-6-release: http://cbs.centos.org/repos/nfv7-opendaylight-6-release/x86_64/os/Packages/
152 .. _nfv7-opendaylight-50-release: http://cbs.centos.org/repos/nfv7-opendaylight-50-release/x86_64/os/Packages/
153 .. _nfv7-opendaylight-51-release: http://cbs.centos.org/repos/nfv7-opendaylight-51-release/x86_64/os/Packages/
154 .. _nfv7-opendaylight-52-release: http://cbs.centos.org/repos/nfv7-opendaylight-52-release/x86_64/os/Packages/
155 .. _nfv7-opendaylight-53-release: http://cbs.centos.org/repos/nfv7-opendaylight-53-release/x86_64/os/Packages/
156 .. _nfv7-opendaylight-60-release: http://cbs.centos.org/repos/nfv7-opendaylight-60-release/x86_64/os/Packages/
157 .. _example repo config files for each official repository: https://git.opendaylight.org/gerrit/gitweb?p=integration/packaging.git;a=tree;f=rpm/example_repo_configs;hb=refs/heads/master