Chris Dent <cdent+os@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 problem. 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 use.

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. -Jim