Re: [Xen-devel] [OSSTEST PATCH v11 20/20] Introduce flight for stable branches of OpenStack

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Fri, Jun 23, 2017 at 06:00:29PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[OSSTEST PATCH v11 20/20] Introduce flight for stable 
> branches of OpenStack"):
> > OpenStack have many different repo which should be in sync, so this
> > patch should grab the revisions of the stable branch of every OpenStack
> > tree. Tempest does not have stable branch and should be able to test any
> > OpenStack version.
> ...
> > +openstack-*-*)
> > +   os_tree="${branch#openstack-}"
> > +   os_tree="${os_tree%-*}"
> > +   branchcore="${branch##*-}"
> > +   eval repo_tree_rev_fetch_git "openstack-$os_tree" \
> > +           "\$TREE_OPENSTACK_${os_tree^^}" "stable/$branchcore" \
> > +                "\$LOCALREV_OPENSTACK_${os_tree^^}"
> 
> From your previous email:
> 
>   I think this patch is confusing because I originally try to use osstest
>   scripts to find which commit to use for every trees and so have add the
>   necessary into ./ap-fetch-version. But I could not make that works
>   without duplicating some functions and so went with writing
>   'origin/stable/ocata' into REVISION_*.
> 
> I think I am indeed still confused by some of it.
> 
> For example:
> 
> > +openstack_rev() {
> > +        local os_tree="$1"
> > +        local os_branch
> > +
> > +        if eval [ "x\$REVISION_OPENSTACK_${os_tree^^}" = x ]; then
> > +                case "$branch" in
> > +                openstack-*-*)
> > +                        os_branch="openstack-$os_tree-${branch##*-}"
> > +                        os_git_branch="origin/stable/${branch##*-}"
> > +                        ;;
> > +                *)
> > +                        os_branch="openstack-$os_tree"
> > +                        os_git_branch="origin/master"
> > +                        ;;
> > +                esac
> > +
> > +                # Use latest version, even for other openstack
> > +                # trees so branch openstack-nova-ocata should have
> > +                # other trees like openstack-neutron have the
> > +                # revision of the same branch fetch at the same
> > +                # time
> > +                if [ "$branch" != "$os_branch" ]; then
> > +                        eval "export 
> > REVISION_OPENSTACK_${os_tree^^}=$os_git_branch"
> > +                        return
> > +                fi
> > +                determine_version "REVISION_OPENSTACK_${os_tree^^}" \
> > +                        "$os_branch" "OPENSTACK_${os_tree^^}"
> > +                eval "export REVISION_OPENSTACK_${os_tree^^}"
> > +        fi
> > +}
> > +for os_tree in cinder devstack glance keystone neutron nova requirements; 
> > do
> > +        openstack_rev "$os_tree"
> > +done
> 
> I wonder if this full generality is really necessary ?  If you don't
> intend branches like   openstack-ocata-neutron   then it would be
> sufficient to call one function for nova and another for the other
> trees.

I'll see what I can do.

> And, frankly, I don't think we could have branches like
> `openstack-ocata-neutron'.  That would be too many branches.

Yes, it was to keep a door open.

> So perhaps the branch `openstack-ocata-nova' should be called
> `openstack-ocata' ?

Yes, I think that would be enough. You mean "openstack-$version" right?
(Or with other words "openstack-$release_name".)

> Also, right now I think it's clear that we're not intending to add
> openstack jobs to existing branches' flights.  But if we were to do
> that in the future, we would want all the subtrees to be tracked.
> 
> Maybe we should have a way for cr-daily-branch to fetch, and push,
> multiple trees.  We could call ap-fetch-version on every tree,
> and set the appropriate variable (with determine_version, as you have
> above).  And then set a variable to call ap-push multiple times, if we
> get a pass.

Yes, I first do the work to have the branches been properly setup to
test openstack of a release, then later I can look into pushing multiple
branches.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel