[openstack-dev] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?

Jeremy Stanley fungi at yuggoth.org
Fri Mar 25 20:52:58 UTC 2016

On 2016-03-25 16:33:44 -0400 (-0400), Jay Pipes wrote:
> What I'm proposing isn't using or needing a custom OpenStack
> deployment. There's nothing non-standard at all about the PCI or
> NFV stuff besides the hardware required to functionally test it.

What you _are_ talking about though is maintaining physical servers
in a data center running an OpenStack environment (and if you want
it participating in gating/preventing changes from merging you need
more than one environment so we don't completely shutdown
development when one of them collapses). This much has been a
challenge for the TripleO team, such that the jobs running for them
are still not voting on their changes.

> What we're talking about here is using the same upstream Infra
> Puppet modules, installed on a long-running server in a lab that
> can interface with upstream Gerrit, respond to new change events
> in the Gerrit stream, and trigger devstack-gate[-like] builds on
> some bare-metal gear.

It's possible I'm misunderstanding you... you're talking about
maintaining a deployment of OpenStack with specific hardware to be
able to run these jobs in, right? That's not as trivial an effort as
it sounds, and I'm skeptical "a couple of operators" is sufficient
to sustain such an endeavor.

> Is that something that is totally out of the question for the
> upstream Infra team to be a guide for?

We've stated in the past that we're willing to accept this level of
integration as long as our requirements for redundancy/uptime are
met. We mostly just don't want to see issues with the environment
block development for projects relying on it because it's the only
place those jobs can run, so multiple environments in different data
centers would be a necessity (right now our gating jobs are able to
run in any of 9 regions from 6 providers, which mitigates this
Jeremy Stanley

More information about the OpenStack-dev mailing list