Andrea Frittoli <> writes:

> I also believe we can find ways to make post-merge / periodic checks useful.
> We need to do that to keep the gate to a sane scale.

Yes, we have a plan to do that that we outlined at the infra/QA meetup
this summer and described to this list in this email:

Particularly this part, but please read the whole message if you have
not already, or have forgotten it:

  * For all non gold standard configurations, we'll dedicate a part of
    our infrastructure to running them in a continuous background loop,
    as well as making these configs available as experimental jobs. The
    idea here is that we'll actually be able to provide more
    configurations that are operating in a more traditional CI (post
    merge) context. People that are interested in keeping these bits
    functional can monitor those jobs and help with fixes when needed.
    The experimental jobs mean that if developers are concerned about
    the effect of a particular change on one of these configs, it's easy
    to request a pre-merge test run.  In the near term we might imagine
    this would allow for things like ceph, mongodb, docker, and possibly
    very new libvirt to be validated in some way upstream.

  * Provide some kind of easy to view dashboards of these jobs, as well
    as a policy that if some job is failing for > some period of time,
    it's removed from the system. We want to provide whatever feedback
    we can to engaged parties, but people do need to realize that
    engagement is key. The biggest part of putting tests into OpenStack
    isn't landing the tests, but dealing with their failures.

I'm glad to see people interested in this.  If you're ready to
contribute to it, please stop by #openstack-infra or join our next team
meeting[1] to discuss how you can help.



OpenStack-dev mailing list

Reply via email to