Open Stack

Bob Ball <bob.ball at citrix.com> writes:

> What are the thoughts on how an external system can add gating
> comments?

This is very unlikely to happen.

Multiple gating systems for one project (or set of projects in our case)
will not work.  Zuul does quite a bit of work to try to merge changes as
quickly as possible, including speculative execution (where it builds
git trees for several projects that represent the expected repo states
in the future after many changes merge).  It also recognizes updates to
the current state of changes in review, determining whether they can
merge based on current review criteria, dependencies, etc.

In other words, Zuul needs a global and authoritative view of what is
happening.  If there is an outside influence that may cause an
unpredictable change (such as a random -2 showing up), Zuul will not be
able to make the correct choices.

There is another important issue -- we can not gate on something that is
not run by the infrastructure team.  We have a responsibility to the
developers of the project to keep this system running.  If something
breaks, any one of several people on the (open; anyone is welcome!)
infrastructure team needs to be able to fix it.  If we started running
gate tests on an external system and it stopped working, development on
the entire project would stop, and we would be powerless to fix it.

On a constructive note, much of what smokestack does could be
incorporated into the current infrastructure.  The "devstack" jenkins
nodes are becoming increasingly inaccurately named, as they are already
running tests that have nothing to do with devstack.  Think of them as
general purpose single-use jenkins slaves.  It would not be too
difficult to have a jenkins job build packages, and then have further
jenkins jobs use those packages to stand up a multi-node openstack (if
you need three nodes, write three jobs that each run on a single-use
full-access slave).  Obviously this would be quite resource intensive,
but I believe it's possible.

The problem, as I understand it, is that we can't run Xen nested on any
of our current cloud providers.  If there is no way to do that, then I
believe we would need a new source of test resources for this.  I think
we talked about this a bit at the summit, but I think in general if
someone wants to provide new testing resources, they would need to be
sufficient to support our resource usage (which is large and growing),
supported by a real ops team (because we aren't one) with something like
an SLA.  We discussed some ideas around bare metal testing at the summit
here: https://etherpad.openstack.org/havana-bare-metal-testing

Even without gating, the advisory reporting from smokestack is hugely
valuable.  I think any increase in reliability and speed (such as
automating the failure detection as you were talking about) will be
perceived by the review community and they will act accordingly, giving
it significant weight in their reviews.

-Jim