Re: [Xen-devel] [OSSTEST PATCH v13 22/24] New branch openstack-ocata

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Anthony PERARD writes ("[OSSTEST PATCH v13 22/24] New branch openstack-ocata"):
> Testing of the Ocata stable branch of OpenStack against Xen unstable.
> 
> OpenStack have many different repo which should be in sync, so we should
> attempd to grab the revisions of the stable branch of every OpenStack
> tree, but for now, the runvars REVISION_* of tree other than nova is set
> to "origin/stable/ocata", except Tempest does not have stable branch and
> should be able to test any OpenStack version.

Ah I see this is where the new branch is created.  You will want to
run standalone-generate-dump-flight-runvars after this, not after the
previous patch (which is fine as it is - sorry, please forget my
comment about editing cr-for-branches there).

I'm afraid I don't understand your explanation about stable branches.
Earlier I asked:

  > Do you intend to provide a version of this patch which maintains a
  > tested branch for all of these different trees ?

  No, I don't. This would be a different patch (and maybe different patch
  series).

So you don't intend to maintain a tested branch for each of these
trees.  But you do intend, I think, to maintain a tested branch of the
main tree.  You say the subtrees "should be in sync", which I take to
mean that openstack upstream only expect it to work if you grab a
revision from all of these trees at "roughty the same time" or
something.

I don't think this will necessarily work properly.  The most obvious
problem I see is that regressions which are introduced in the subtrees
will be picked up by even flights which are attempting to use a
working (ie osstest-tested) version of "openstack".

This may not be critical if openstack jobs appear only on the flights
for openstack branches.  openstack branches will occasionally suffer
trouble but things will probably be BALGE.

But we definitely won't be able to add openstack tests to the other
branches without doing something different.

I have a very strong feeling we have discussed this before but I'm
afraid the answer doesn't seem to have been written down somewhere I
can easily find it.  It should be explained in your series somewhere,
in a comment or a commit message.

It would also be nice to have a theory about how this could be
improved in the future.  That would mean we could be more confident
that we're not painting ourselves into a corner.

Having said all that, with a suitable explanation, I think the code is
probably about right.

Ian.

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