On 06/18/2014 06:46 PM, Eoghan Glynn wrote: > If we were to use f20 more widely in the gate (not to entirely > supplant precise, more just to split the load more evenly) then > would the problem observed tend to naturally resolve itself?
I would be happy to see that, having spent some time on the Fedora bring-up :) However I guess there is a chicken-egg problem with large-scale roll-out in that the platform isn't quite stable yet. We've hit some things that only really become apparent "in the wild"; differences between Rackspace & HP images, issues running on Xen which we don't test much, the odd upstream bug requiring work-arounds [1], etc. It did seem that devstack changes was the best place to stabilze the job. However, as is apparent, devstack changes often need to be pushed through quickly and that does not match well with a slightly unstable job. Having it experimental in devstack isn't much help in stabilizing. If I trigger experimental builds for every devstack change it runs several other jobs too, so really I've just increased contention for limited resources by doing that. I say this *has* to be running for devstack eventually to stop the fairly frequent breakage of devstack on Fedora, which causes a lot of people wasted time often chasing the same bugs. But in the mean time, maybe suggestions for getting the Fedora job exposure somewhere else where it can brew and stabilize are a good idea. We could make a special queue just for f20 that only triggers that job, if others like that idea. Otherwise, ceilometer maybe? I made some WIP patches [2,3] for this already. I think it's close, just deciding what tempest tests to match for the job in [2]. Thanks, -i [1] https://bugzilla.redhat.com/show_bug.cgi?id=1099031 [2] https://review.openstack.org/#/c/96316/ [3] https://review.openstack.org/#/c/96317/ _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
