On 06/12/2014 08:36 AM, Sean Dague wrote: > On 06/12/2014 10:38 AM, Mike Bayer wrote: >> >> On 6/12/14, 8:26 AM, Julien Danjou wrote: >>> On Thu, Jun 12 2014, Sean Dague wrote: >>> >>>> That's not cacthable in unit or functional tests? >>> Not in an accurate manner, no. >>> >>>> Keeping jobs alive based on the theory that they might one day be useful >>>> is something we just don't have the liberty to do any more. We've not >>>> seen an idle node in zuul in 2 days... and we're only at j-1. j-3 will >>>> be at least +50% of this load. >>> Sure, I'm not saying we don't have a problem. I'm just saying it's not a >>> good solution to fix that problem IMHO. >> >> Just my 2c without having a full understanding of all of OpenStack's CI >> environment, Postgresql is definitely different enough that MySQL >> "strict mode" could still allow issues to slip through quite easily, and >> also as far as capacity issues, this might be longer term but I'm hoping >> to get database-related tests to be lots faster if we can move to a >> model that spends much less time creating databases and schemas. > > This is what I mean by functional testing. If we were directly hitting a > real database on a set of in tree project tests, I think you could > discover issues like this. Neutron was headed down that path.
We have MySQL and PostGres available on all of the unittest nodes. So if someone wrote a functional test to test for postgres specific issues like that, and put the standard trap on it "only run this if you find a postgres database with an openstackci user" - then we should be able to catch all of the specific things like this without incurring the cost of a double run. So, in general, +1 from me. > But if we're talking about a devstack / tempest run, it's not really > applicable. > > If someone can point me to a case where we've actually found this kind > of bug with tempest / devstack, that would be great. I've just *never* > seen it. I was the one that did most of the fixing for pg support in > Nova, and have helped other projects as well, so I'm relatively familiar > with the kinds of fails we can discover. The ones that Julien pointed > really aren't likely to be exposed in our current system. > > Which is why I think we're mostly just burning cycles on the existing > approach for no gain. > > -Sean > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
