On Mon, Jun 16, 2014 at 11:38 AM, Joe Gordon <joe.gord...@gmail.com> wrote: > > > > 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? > This is on my radar for Juno-2. I'll syncup with some folks in-channel on what the next steps would be to make this happen.
Kyle >> >> >> 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
