[openstack-dev] [Zun] Relocate jobs from openstack/zun to openstack/zun-tempest-plugin
hongbin034 at gmail.com
Thu May 17 02:05:04 UTC 2018
On Wed, May 16, 2018 at 7:02 PM, James E. Blair <corvus at inaugust.com> wrote:
> Hongbin Lu <hongbin034 at gmail.com> writes:
> > The goal of those patches is to move the job definitions and playbooks
> > openstack/zun to openstack/zun-tempest-plugin. The advantages of such
> > change are as following:
> > * Make job definitions closer to tempest test cases so that it is optimal
> > for development and code reviews workflow. For example, sometime, we can
> > avoid to split a patch into two repos in order to add a simple tempest
> > case.
> > * openstack/zun is branched and openstack/zun-tempest-plugin is
> > Zuul job definitions seem to fit better into branchless context.
> > * It saves us the overhead to backport job definitions to stable branch.
> > Sometime, missing a backport might lead to gate breakage and blocking
> > development workflow.
> Just a minor clarification: it's not always the case that branchless is
> Jobs which operate on repos that are branched are likely to be easier to
> work with in the long run, as whatever configuration is specific to the
> branch appears on that branch, instead of somewhere else.
> Further, there shouldn't be a need to backport changes once the initial
> jobs are set up. In the future, when you branch master to stable/foo,
> you'll automatically get a copy of the job that's appropriate for that
> point in time, and you only need to update it if you're already updating
> the software on that branch. Older versions of jobs on stable branches
> can continue to use their old configuration.
> For jobs which should perform the same function on all branches, it is
> easier to have those defined in branchless repos. But in either case,
> you can accomplish the same thing without moving jobs. In a branched
> repo, you can add a "branches: .*" matcher, and in a branchless repo,
> you can add multiple variants for each branch.
> The new v3-native devstack jobs are branched, and are defined in the
> devstack repo. They define how to set up devstack for each branch. But
> the tempest jobs (which build on top of the devstack jobs), are not
> branched (just like tempest), since they are designed to run the same
> way on all branches.
> I don't know enough about the situation to recommend one way or the
> other for Zun. But I do want to emphasize that the best answer depends
> on the circumstances.
Thanks a lot for sharing your expertise. Based on what you said, I
re-visited the Zun's situation and think the branchless approach might not
In before, I ran into a situation that I wanted to write a tempest test
case with a specific API microversion. In order to get it setup, it seems I
need to submit three patches: a tempest test case (at zun-tempest-plugin),
a tempest config to populate the min/max microversion (at zun master) and a
backport (at zun stable/queens). A simple change that needs to be splited
into three patches made me revisit the current layout and explore the
branchless approach that are exercised in neutron .
I am re-visiting the situation now and leaning to the branched approach
because the setup of microversion min/max seems to be just once per branch.
However, I am not sure though how often we will run into a similar
situation that a change in tempest test case is coupled with job config. If
it frequently happens in the future, switching to branchless approach might
be more convenient.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev