Open Stack

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
> 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.

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 
good one.

Best,
-jay