Open Stack

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
> from
> > 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
> test
> > case.
> > * openstack/zun is branched and openstack/zun-tempest-plugin is
> branchless.
> > 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
> better.
>
> 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.
>

Hi Jim,

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
be better.

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 [1].

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.

[1]
https://github.com/openstack/neutron-tempest-plugin/blob/master/.zuul.yaml

Best regards,
Hongbin


>
> -Jim
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180516/71ac716d/attachment.html>