On Wed, May 16, 2018 at 7:02 PM, James E. Blair <cor...@inaugust.com> wrote:
> Hongbin Lu <hongbin...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev