Dear all,

- tempest-full-queens and tempest-full-py3-queens are now available for
testing of branchless repositories [0]. They are used for tempest and
devstack-gate. If you own a tempest plugin in a branchless repo, you may
consider adding similar jobs to your plugin if you use it for tests on
stable/queen as well.
- if you have migrated jobs based on devstack-tempest please let me know,
I'm building reference docs and I'd like to include as many examples as
- work on multi-node is in progress, but not ready still - you can follow
the patches in the multinode branch [1]
- updates on some of the points from my previous email are inline below

Andrea Frittoli (andreaf)


On Thu, Feb 15, 2018 at 11:31 PM Andrea Frittoli <>

> Dear all,
> this is the first or a series of ~regular updates on the migration of
> Tempest / Grenade jobs to  Zuul v3 native.
> The QA team together with the infra team are working on providing the
> OpenStack community with a set of base Tempest / Grenade jobs that can be
> used as a basis to write new CI jobs / migrate existing legacy ones with a
> minimal effort and very little or no Ansible knowledge as a precondition.
> The effort is tracked in an etherpad [0]; I'm trying to keep the
> etherpad up to date but it may not always be a source of truth.
> Useful jobs available so far:
> - devstack-tempest [0] is a simple tempest/devstack job that runs keystone
> glance nova cinder neutron swift and tempest *smoke* filter
> - tempest-full [1] is similar but runs a full test run - it replaces the
> legacy tempest-dsvm-neutron-full from the integrated gate
> - tempest-full-py3 [2] runs a full test run on python3 - it replaces the
> legacy tempest-dsvm-py35

Some more details on this topic: what I did not mention in my previous
email is that the autogenerated Tempest / Grenade CI jobs (legacy-*
playbooks) are not meant to be used as a basis for Zuul V3 native jobs. To
create Zuul V3 Tempest / Grenade native jobs for your projects you need to
through away the legacy playbooks and defined new jobs in .zuul.yaml, as
documented in the zuul v3 docs [2].
The parent job for a single node Tempest job will usually be
devstack-tempest. Example migrated jobs are avilable, for instance: [3] [4].




> Both tempest-full and tempest-full-py3 are part of integrated-gate
> templates, starting from stable/queens on.
> The other stable branches still run the legacy jobs, since
> devstack ansible changes have not been backported (yet). If we do backport
> it will be up to pike maximum.
> Those jobs work in single node mode only at the moment. Enabling multinode
> via job configuration only require a new Zuul feature [4][5] that should be
> available soon; the new feature allows defining host/group variables in the
> job definition, which means setting variables which are specific to one
> host or a group of hosts.
> Multinode DVR and Ironic jobs will require migration of the ovs-* roles
> form devstack-gate to devstack as well.
> Grenade jobs (single and multinode) are still legacy, even if the *legacy*
> word has been removed from the name.
> They are currently temporarily hosted in the neutron repository. They are
> going to be implemented as Zuul v3 native in the grenade repository.
> Roles are documented, and a couple of migration tips for DEVSTACK_GATE
> flags is available in the etherpad [0]; more comprehensive examples /
> docs will be available as soon as possible.
> Please let me know if you find this update useful and / or if you would
> like to see different information in it.
> I will send further updates as soon as significant changes / new features
> become available.
> Andrea Frittoli (andreaf)
> [0]
> [1]
> [2]
> [3]
> [4]
> [5]
OpenStack Development Mailing List (not for usage questions)

Reply via email to