[openstack-dev] Gate proposal - drop Postgresql configurations in the gate
Joe Gordon
joe.gordon0 at gmail.com
Thu Jun 12 16:24:15 UTC 2014
On Jun 12, 2014 8:37 AM, "Sean Dague" <sean at dague.net> 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.
>
> 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.
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.
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.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140612/8c0eeb97/attachment-0001.html>
More information about the OpenStack-dev
mailing list