[openstack-dev] Gate proposal - drop Postgresql configurations in the gate
jaypipes at gmail.com
Thu Jun 12 20:12:26 UTC 2014
On 06/12/2014 12:24 PM, Joe Gordon wrote:
> On Jun 12, 2014 8:37 AM, "Sean Dague" <sean at dague.net
> <mailto: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
> > >>> 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
> > >>> 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
> > > 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.
I was initially -1 on Sean's proposal. My reasoning echoed some of
Julien's reasoning and all of Chris Friesen's rationale (and the bug
report he mentioned was a perfect example of the types of things that
would not, IMO, be caught by a MySQL strict mode configuration.)
That said, I recognize the resource capacity issues the gate is
suffering from and I think Joe's suggestion above is actually a really
More information about the OpenStack-dev