On Sat, Jun 14, 2014 at 3:46 AM, Sean Dague <s...@dague.net> wrote: > On 06/13/2014 06:47 PM, Joe Gordon wrote: > > > > > > > > On Thu, Jun 12, 2014 at 7:18 PM, Dan Prince <dpri...@redhat.com > > <mailto:dpri...@redhat.com>> wrote: > > > > On Thu, 2014-06-12 at 09:24 -0700, Joe Gordon wrote: > > > > > > On Jun 12, 2014 8:37 AM, "Sean Dague" <s...@dague.net > > <mailto:s...@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'd be fine with this tradeoff if it allows us to keep PostgreSQL in > the > > mix. > > > > > > Here is my proposed change to how we handle postgres in the gate: > > > > https://review.openstack.org/#/c/100033 > > > > > > Merge postgres and neutron jobs in integrated-gate template > > > > > > > > > > Instead of having a separate job for postgres and neutron, combine them. > > In the integrated-gate we will only test postgres+neutron and not > > > > > > neutron/mysql or nova-network/postgres. > > > > * neutron/mysql is still tested in integrated-gate-neutron > > * nova-network/postgres is tested in nova > > Because neutron only runs smoke jobs, this actually drops all the > interesting testing of pg. The things I've actually seen catch > differences are the nova negative tests, which basically aren't run in > this job. >
I forgot about the smoke test only part when I originally proposed this. >From a cursory look, neutron-full appears to be fairly stable, so if we move over to neutron-full in the near future that should address your concerns. Are there plans to move over to neutron-full in the near future? > > So I think that's kind of the worst of all possible worlds, because it > would make people think the thing is tested interestingly, when it's not. > > -Sean > > -- > Sean Dague > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev