Bob Ball <[email protected]> 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 _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
