Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140612/31b3676f/attachment.pgp>