<p dir="ltr"><br>
On Jun 12, 2014 8:37 AM, "Sean Dague" <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
><br>
> On 06/12/2014 10:38 AM, Mike Bayer wrote:<br>
> ><br>
> > On 6/12/14, 8:26 AM, Julien Danjou wrote:<br>
> >> On Thu, Jun 12 2014, Sean Dague wrote:<br>
> >><br>
> >>> That's not cacthable in unit or functional tests?<br>
> >> Not in an accurate manner, no.<br>
> >><br>
> >>> Keeping jobs alive based on the theory that they might one day be useful<br>
> >>> is something we just don't have the liberty to do any more. We've not<br>
> >>> seen an idle node in zuul in 2 days... and we're only at j-1. j-3 will<br>
> >>> be at least +50% of this load.<br>
> >> Sure, I'm not saying we don't have a problem. I'm just saying it's not a<br>
> >> good solution to fix that problem IMHO.<br>
> ><br>
> > Just my 2c without having a full understanding of all of OpenStack's CI<br>
> > environment, Postgresql is definitely different enough that MySQL<br>
> > "strict mode" could still allow issues to slip through quite easily, and<br>
> > also as far as capacity issues, this might be longer term but I'm hoping<br>
> > to get database-related tests to be lots faster if we can move to a<br>
> > model that spends much less time creating databases and schemas.<br>
><br>
> This is what I mean by functional testing. If we were directly hitting a<br>
> real database on a set of in tree project tests, I think you could<br>
> discover issues like this. Neutron was headed down that path.<br>
><br>
> But if we're talking about a devstack / tempest run, it's not really<br>
> applicable.<br>
><br>
> If someone can point me to a case where we've actually found this kind<br>
> of bug with tempest / devstack, that would be great. I've just *never*<br>
> seen it. I was the one that did most of the fixing for pg support in<br>
> Nova, and have helped other projects as well, so I'm relatively familiar<br>
> with the kinds of fails we can discover. The ones that Julien pointed<br>
> really aren't likely to be exposed in our current system.<br>
><br>
> Which is why I think we're mostly just burning cycles on the existing<br>
> approach for no gain.</p>
<p dir="ltr">Given all the points made above, I think dropping PostgreSQL is the right choice; if only we had infinite cloud that would be another story.</p>
<p dir="ltr">What about converting one of our existing jobs (grenade partial ncpu, large ops, regular grenade, tempest with nova network etc.) Into a PostgreSQL only job? We could get some level of PostgreSQL testing without any additional jobs, although this is  tradeoff obviously.</p>

<p dir="ltr">><br>
>         -Sean<br>
><br>
> --<br>
> Sean Dague<br>
> <a href="http://dague.net">http://dague.net</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
</p>