Open Stack

On Thu, Jun 12, 2014 at 7:18 PM, Dan Prince <dprince at redhat.com> wrote:

> On Thu, 2014-06-12 at 09:24 -0700, Joe Gordon wrote:
> >
> > 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.
>
> 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


>
> >
> >         -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
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
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/20140613/412913a0/attachment.html>