[openstack-dev] [infra][devstack][gnocchi] Unable to run devstack-gate with stable/1.3

Clark Boylan cboylan at sapwetik.org
Fri Nov 20 12:54:17 UTC 2015


On Thu, Nov 19, 2015, at 05:17 AM, Julien Danjou wrote:
> Hi,
> 
> The Gnocchi gate is broken for stable/1.3 because of devstack-gate
> saying¹:
>   ERROR: branch not allowed by features matrix: 1.3
> 
> From what I understand, that's because devstack-gate thinks it should
> try to pull stable/1.3 for devstack & all OpenStack projects, branch
> that does not exist – and make no sense elsewhere than in Gnocchi.
No, this isn't why this is happening. Devstack-gate will happily
fallback to grabbing master for projects if it doesn't otherwise find
the branch for the change under test in other projects. The issue is
that in order to run devstack you have to configure a set of services in
devstack and the services you want to run change over time because we
make releases and new services show up and old services go away.

As a result devstack-gate is very explicit about what should be
configured for each release [0]. If it doesn't recognize the branch
currently under test it fails rather than doing something implcitly that
is unexpected.
> 
> In the past, we set OVERRIDE_ZUUL_BRANCH=stable/kilo in the Gnocchi jobs
> for some stable branches (we did for stable/1.0), but honestly patching
> the infra each time we do a stable release is getting painful.
You need a mapping of some sort. How should devstack be configured for
stable/X.Y? What about stable/Y.Z? This is one method of providing that
mapping and it is very explicit. We can probably do better but we need
to understand what the desired mapping is before encoding that into any
tools.
> 
> Actually, Gnocchi does not really care about pulling whatever branch of
> the other projects, it just wants them deployed to use them (Keystone
> and Swift). Since the simplest way is to use devstack, that's what it
> uses.
If you have a very specific concrete set of services to be configured
you could possibly ship your own features.yaml to only configure those
things (rather than the default of an entire running cloud). This may
help make the jobs run quicker too.

Another approach would be to set the OVERRIDE_ZUUL_BRANCH to master and
the OVERRIDE_${project}_PROJECT_BRANCH to ZUUL_BRANCH so that your
project is always checked out against the correct branch for the change
but is tested against master everything else. This is probably the
simplest mapping (our stable/X.Y should run against whatever is
current).
> 
> Is there any chance we can have a way to say in devstack{,-gate} "just
> deploy the latest released version of $PROJECT" and that's it?
I think there are several options but which one is used depends on how
you need to map onto the 6 month release cycle (required because
devstack deploys projects using it).

[0]
https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/features.yaml#n3

Hope this helps,
Clark



More information about the OpenStack-dev mailing list