blob: 633f951d3d3cd60564f278dc0f0600ee89670d72 [file] [log] [blame]
Andrea Frittolif32f3f52018-02-19 21:45:22 +00001===============================
2Migrating Zuul V2 CI jobs to V3
3===============================
4
5The OpenStack CI system moved from Zuul v2 to Zuul v3, and all CI jobs moved to
6the new CI system. All jobs have been migrated automatically to a format
7compatible with Zuul v3; the jobs produced in this way however are suboptimal
8and do not use the capabilities introduced by Zuul v3, which allow for re-use of
9job parts, in the form of Ansible roles, as well as inheritance between jobs.
10
11DevStack hosts a set of roles, plays and jobs that can be used by other
12repositories to define their DevStack based jobs. To benefit from them, jobs
13must be migrated from the legacy v2 ones into v3 native format.
14
15This document provides guidance and examples to make the migration process as
16painless and smooth as possible.
17
18Where to host the job definitions.
19==================================
20
21In Zuul V3 jobs can be defined in the repository that contains the code they
22excercise. If you are writing CI jobs for an OpenStack service you can define
23your DevStack based CI jobs in one of the repositories that host the code for
24your service. If you have a branchless repo, like a Tempest plugin, that is
25a convenient choice to host the job definitions since job changes do not have
26to be backported. For example, see the beginning of the ``.zuul.yaml`` from the
27sahara Tempest plugin repo:
28
29.. code:: yaml
30
31 # In http://git.openstack.org/cgit/openstack/sahara-tests/tree/.zuul.yaml:
32 - job:
33 name: sahara-tests-tempest
34 description: |
35 Run Tempest tests from the Sahara plugin.
36 parent: devstack-tempest
37
38Which base job to start from
39============================
40
41If your job needs an OpenStack cloud deployed via DevStack, but you don't plan
42on running Tempest tests, you can start from one of the base
43:doc:`jobs <zuul_jobs>` defined in the DevStack repo.
44
45The ``devstack`` job can be used for both single-node jobs and multi-node jobs,
46and it includes the list of services used in the integrated gate (keystone,
47glance, nova, cinder, neutron and swift). Different topologies can be achieved
48by switching the nodeset used in the child job.
49
50The ``devstack-base`` job is similar to ``devstack`` but it does not specify any
51required repo or service to be run in DevStack. It can be useful to setup
52children jobs that use a very narrow DevStack setup.
53
54If your job needs an OpenStack cloud deployed via DevStack, and you do plan
55on running Tempest tests, you can start from one of the base jobs defined in the
56Tempest repo.
57
58The ``devstack-tempest`` job can be used for both single-node jobs and
59multi-node jobs. Different topologies can be achieved by switching the nodeset
60used in the child job.
61
62Jobs can be customized as follows without writing any Ansible code:
63
64- add and/or remove DevStack services
65- add or modify DevStack and services configuration
66- install DevStack plugins
67- extend the number of sub-nodes (multinode only)
68- define extra log files and/or directories to be uploaded on logs.o.o
69- define extra log file extensions to be rewritten to .txt for ease of access
70
71Tempest jobs can be further customized as follows:
72
73- define the Tempest tox environment to be used
74- define the test concurrency
75- define the test regular expression
76
77Writing Ansible code, or importing existing custom roles, jobs can be further
78extended by:
79
80- adding pre and/or post playbooks
81- overriding the run playbook, add custom roles
82
83The (partial) example below extends a Tempest single node base job
84"devstack-tempest" in the Kuryr repository. The parent job name is defined in
85job.parent.
86
87.. code:: yaml
88
89 # https://git.openstack.org/cgit/openstack/kuryr-kubernetes/tree/.zuul.yaml:
90 - job:
91 name: kuryr-kubernetes-tempest-base
92 parent: devstack-tempest
93 description: Base kuryr-kubernetes-job
94 required-projects:
95 - openstack/devstack-plugin-container
96 - openstack/kuryr
97 - openstack/kuryr-kubernetes
98 - openstack/kuryr-tempest-plugin
99 - openstack/neutron-lbaas
100 vars:
101 tempest_test_regex: '^(kuryr_tempest_plugin.tests.)'
102 tox_envlist: 'all'
103 devstack_localrc:
104 KURYR_K8S_API_PORT: 8080
Andrea Frittolif32f3f52018-02-19 21:45:22 +0000105 devstack_services:
106 kubernetes-api: true
107 kubernetes-controller-manager: true
108 kubernetes-scheduler: true
109 kubelet: true
110 kuryr-kubernetes: true
111 (...)
112 devstack_plugins:
113 kuryr-kubernetes: https://git.openstack.org/openstack/kuryr
114 devstack-plugin-container: https://git.openstack.org/openstack/devstack-plugin-container
115 neutron-lbaas: https://git.openstack.org/openstack/neutron-lbaas
Luigi Toscano70d043d2019-03-12 22:25:44 +0100116 tempest_plugins:
117 - kuryr-tempest-plugin
Andrea Frittolif32f3f52018-02-19 21:45:22 +0000118 (...)
119
120Job variables
121=============
122
123Variables can be added to the job in three different places:
124
125- job.vars: these are global variables available to all node in the nodeset
126- job.host-vars.[HOST]: these are variables available only to the specified HOST
127- job.group-vars.[GROUP]: these are variables available only to the specified
128 GROUP
129
130Zuul merges dict variables through job inheritance. Host and group variables
131override variables with the same name defined as global variables.
132
133In the example below, for the sundaes job, hosts that are not part of the
134subnode group will run vanilla and chocolate. Hosts in the subnode group will
135run stracciatella and strawberry.
136
137.. code:: yaml
138
139 - job:
140 name: ice-creams
141 vars:
142 devstack_service:
143 vanilla: true
144 chocolate: false
145 group-vars:
146 subnode:
147 devstack_service:
148 pistacchio: true
149 stracciatella: true
150
151 - job:
152 name: sundaes
153 parent: ice-creams
154 vars:
155 devstack_service:
156 chocolate: true
157 group-vars:
158 subnode:
159 devstack_service:
160 strawberry: true
161 pistacchio: false
162
163
164DevStack Gate Flags
165===================
166
167The old CI system worked using a combination of DevStack, Tempest and
168devstack-gate to setup a test environment and run tests against it. With Zuul
169V3, the logic that used to live in devstack-gate is moved into different repos,
170including DevStack, Tempest and grenade.
171
172DevStack-gate exposes an interface for job definition based on a number of
173DEVSTACK_GATE_* environment variables, or flags. This guide shows how to map
174DEVSTACK_GATE flags into the new
175system.
176
177The repo column indicates in which repository is hosted the code that replaces
178the devstack-gate flag. The new implementation column explains how to reproduce
179the same or a similar behaviour in Zuul v3 jobs. For localrc settings,
180devstack-gate defined a default value. In ansible jobs the default is either the
181value defined in the parent job, or the default from DevStack, if any.
182
183============================================== ============= ==================
184DevStack gate flag Repo New implementation
185============================================== ============= ==================
186OVERRIDE_ZUUL_BRANCH zuul override-checkout:
187 [branch]
188 in the job definition.
189DEVSTACK_GATE_NET_OVERLAY zuul-jobs A bridge called
190 br-infra is set up for
191 all jobs that inherit
192 from multinode with
193 a dedicated `bridge role <https://docs.openstack.org/infra/zuul-jobs/roles.html#role-multi-node-bridge>`_.
194DEVSTACK_GATE_FEATURE_MATRIX devstack-gate ``test_matrix_features``
195 variable of the
196 test-matrix role in
197 devstack-gate. This
198 is a temporary
199 solution, feature
200 matrix will go away.
201 In the future services
202 will be defined in
203 jobs only.
204DEVSTACK_CINDER_VOLUME_CLEAR devstack *CINDER_VOLUME_CLEAR: true/false*
205 in devstack_localrc
206 in the job vars.
207DEVSTACK_GATE_NEUTRON devstack True by default. To
208 disable, disable all
209 neutron services in
210 devstack_services in
211 the job definition.
212DEVSTACK_GATE_CONFIGDRIVE devstack *FORCE_CONFIG_DRIVE: true/false*
213 in devstack_localrc
214 in the job vars.
215DEVSTACK_GATE_INSTALL_TESTONLY devstack *INSTALL_TESTONLY_PACKAGES: true/false*
216 in devstack_localrc
217 in the job vars.
218DEVSTACK_GATE_VIRT_DRIVER devstack *VIRT_DRIVER: [virt driver]*
219 in devstack_localrc
220 in the job vars.
221DEVSTACK_GATE_LIBVIRT_TYPE devstack *LIBVIRT_TYPE: [libvirt type]*
222 in devstack_localrc
223 in the job vars.
224DEVSTACK_GATE_TEMPEST devstack Defined by the job
225 tempest that is used. The
226 ``devstack`` job only
227 runs devstack.
228 The ``devstack-tempest``
229 one triggers a Tempest
230 run as well.
231DEVSTACK_GATE_TEMPEST_FULL tempest *tox_envlist: full*
232 in the job vars.
233DEVSTACK_GATE_TEMPEST_ALL tempest *tox_envlist: all*
234 in the job vars.
235DEVSTACK_GATE_TEMPEST_ALL_PLUGINS tempest *tox_envlist: all-plugin*
236 in the job vars.
237DEVSTACK_GATE_TEMPEST_SCENARIOS tempest *tox_envlist: scenario*
238 in the job vars.
239TEMPEST_CONCURRENCY tempest *tempest_concurrency: [value]*
240 in the job vars. This
241 is available only on
242 jobs that inherit from
243 ``devstack-tempest``
244 down.
245DEVSTACK_GATE_TEMPEST_NOTESTS tempest *tox_envlist: venv-tempest*
246 in the job vars. This
247 will create Tempest
248 virtual environment
249 but run no tests.
250DEVSTACK_GATE_SMOKE_SERIAL tempest *tox_envlist: smoke-serial*
251 in the job vars.
252DEVSTACK_GATE_TEMPEST_DISABLE_TENANT_ISOLATION tempest *tox_envlist: full-serial*
253 in the job vars.
254 *TEMPEST_ALLOW_TENANT_ISOLATION: false*
255 in devstack_localrc in
256 the job vars.
257============================================== ============= ==================
258
259The following flags have not been migrated yet or are legacy and won't be
260migrated at all.
261
262===================================== ====== ==========================
263DevStack gate flag Status Details
264===================================== ====== ==========================
265DEVSTACK_GATE_TOPOLOGY WIP The topology depends on the base
266 job that is used and more
267 specifically on the nodeset
268 attached to it. The new job
269 format allows project to define
270 the variables to be passed to
271 every node/node-group that exists
272 in the topology. Named topologies
273 that include the nodeset and the
274 matching variables can be defined
275 in the form of base jobs.
276DEVSTACK_GATE_GRENADE TBD Grenade Zuul V3 jobs will be
277 hosted in the grenade repo.
278GRENADE_BASE_BRANCH TBD Grenade Zuul V3 jobs will be
279 hosted in the grenade repo.
280DEVSTACK_GATE_NEUTRON_DVR TBD Depends on multinode support.
281DEVSTACK_GATE_EXERCISES TBD Can be done on request.
282DEVSTACK_GATE_IRONIC TBD This will probably be implemented
283 on ironic side.
284DEVSTACK_GATE_IRONIC_DRIVER TBD This will probably be implemented
285 on ironic side.
286DEVSTACK_GATE_IRONIC_BUILD_RAMDISK TBD This will probably be implemented
287 on ironic side.
288DEVSTACK_GATE_POSTGRES Legacy This flag exists in d-g but the
289 only thing that it does is
290 capture postgres logs. This is
291 already supported by the roles in
292 post, so the flag is useless in
293 the new jobs. postgres itself can
294 be enabled via the
295 devstack_service job variable.
296DEVSTACK_GATE_ZEROMQ Legacy This has no effect in d-g.
297DEVSTACK_GATE_MQ_DRIVER Legacy This has no effect in d-g.
298DEVSTACK_GATE_TEMPEST_STRESS_ARGS Legacy Stress is not in Tempest anymore.
299DEVSTACK_GATE_TEMPEST_HEAT_SLOW Legacy This is not used anywhere.
300DEVSTACK_GATE_CELLS Legacy This has no effect in d-g.
301DEVSTACK_GATE_NOVA_API_METADATA_SPLIT Legacy This has no effect in d-g.
302===================================== ====== ==========================