[placement][nova][infra] best way to add to required-projects on several zuul jobs

James E. Blair corvus at inaugust.com
Mon Apr 1 23:15:01 UTC 2019

Chris Dent <cdent+os at anticdent.org> writes:

> The extraction of placement led to the development of os-traits and
> os-resource-classes [1,2] which are python modules which contain
> symbols that represent "blessed" strings used as traits and resource
> classes in at least nova, placement and neutron, but plenty of
> others soon.
> These symbols are actively used when developing new features, so
> being able to access the python modules via tox-siblings [3] in both
> unit and functional tests, from multiple projects, would be grand:
> developers could depends-on changes in modules as they are being
> developed, or rely on symbols in master of the modules before there
> is a release to pypi.
> What is the best way to do this? Many projects are using templates
> like "openstack-python-jobs" but as far as I can tell there's no
> easy way to override just a part of a template in a local .zuul.yaml
> and the usual thing is to create another template such as
> "openstack-python-jobs-neutron" which re-lists all the jobs within,
> and adds a custom required-projects to each job.

While technically you can override settings from a project-template in a
project stanza, when the templates are as simple as those under
discussion, it's exactly as much typing as either omitting the template
or creating a new one (since you have to identify the job and pipeline
whose attributes you want to override).

We have bandied about the idea of adding project-level
requires-projects, and may still do so, though that may not be an
entirely satisfactory solution if there are any jobs where you don't
want the siblings behavior to manifest -- you would have the opposite

Which leads me to a point which I didn't see explicitly addressed in
your email (though it may have been implicitly addressed): there are
some cases where the siblings behavior is desired, and some where it
isn't.  The siblings behavior helps test multiple project integration
before release, but disallowing it ensures that projects can't depend on
unreleased features.  In some situations one behavior is desired, in
others, the other, and in some, both (and in those cases, projects run
two versions of jobs, with and without siblings).  Just make sure to
keep those caveats in mind when choosing which of the three options to

> Is this (creating another template) the right/best way to add to
> required-projects for this kind of thing? If not, what's the best
> way? Presumably it is better to create a centralized job or template
> when >1 projects will need the additional libraries?

I don't have any rabbits to pull out.

I think a template shared between the involved projects makes sense.

I would also consider creating a new job or jobs (either in addition or
in preference to creating the template).  By the time you're describing
a system that requires multiple dependent projects to test, the idea of
a "placement-tox-py35" job starts to become somewhat descriptive.


More information about the openstack-discuss mailing list