<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 14, 2014 at 3:46 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 06/13/2014 06:47 PM, Joe Gordon wrote:<br>
><br>
><br>
><br>
> On Thu, Jun 12, 2014 at 7:18 PM, Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a><br>
</div><div class="">> <mailto:<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>>> wrote:<br>
><br>
> On Thu, 2014-06-12 at 09:24 -0700, Joe Gordon wrote:<br>
> ><br>
> > On Jun 12, 2014 8:37 AM, "Sean Dague" <<a href="mailto:sean@dague.net">sean@dague.net</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:sean@dague.net">sean@dague.net</a>>> wrote:<br>
> > ><br>
> > > On 06/12/2014 10:38 AM, Mike Bayer wrote:<br>
> > > ><br>
> > > > On 6/12/14, 8:26 AM, Julien Danjou wrote:<br>
> > > >> On Thu, Jun 12 2014, Sean Dague wrote:<br>
> > > >><br>
> > > >>> That's not cacthable in unit or functional tests?<br>
> > > >> Not in an accurate manner, no.<br>
> > > >><br>
> > > >>> Keeping jobs alive based on the theory that they might one day<br>
> > be useful<br>
> > > >>> is something we just don't have the liberty to do any more.<br>
> > We've not<br>
> > > >>> seen an idle node in zuul in 2 days... and we're only at j-1.<br>
> > j-3 will<br>
> > > >>> be at least +50% of this load.<br>
> > > >> Sure, I'm not saying we don't have a problem. I'm just saying<br>
> > it's not a<br>
> > > >> good solution to fix that problem IMHO.<br>
> > > ><br>
> > > > Just my 2c without having a full understanding of all of<br>
> > OpenStack's CI<br>
> > > > environment, Postgresql is definitely different enough that MySQL<br>
> > > > "strict mode" could still allow issues to slip through quite<br>
> > easily, and<br>
> > > > also as far as capacity issues, this might be longer term but I'm<br>
> > hoping<br>
> > > > to get database-related tests to be lots faster if we can move to<br>
> > a<br>
> > > > model that spends much less time creating databases and schemas.<br>
> > ><br>
> > > This is what I mean by functional testing. If we were directly<br>
> > hitting a<br>
> > > real database on a set of in tree project tests, I think you could<br>
> > > discover issues like this. Neutron was headed down that path.<br>
> > ><br>
> > > But if we're talking about a devstack / tempest run, it's not really<br>
> > > applicable.<br>
> > ><br>
> > > If someone can point me to a case where we've actually found this<br>
> > kind<br>
> > > of bug with tempest / devstack, that would be great. I've just<br>
> > *never*<br>
> > > seen it. I was the one that did most of the fixing for pg support in<br>
> > > Nova, and have helped other projects as well, so I'm relatively<br>
> > familiar<br>
> > > with the kinds of fails we can discover. The ones that Julien<br>
> > pointed<br>
> > > really aren't likely to be exposed in our current system.<br>
> > ><br>
> > > Which is why I think we're mostly just burning cycles on the<br>
> > existing<br>
> > > approach for no gain.<br>
> ><br>
> > Given all the points made above, I think dropping PostgreSQL is the<br>
> > right choice; if only we had infinite cloud that would be another<br>
> > story.<br>
> ><br>
> > What about converting one of our existing jobs (grenade partial ncpu,<br>
> > large ops, regular grenade, tempest with nova network etc.) Into a<br>
> > PostgreSQL only job? We could get some level of PostgreSQL testing<br>
> > without any additional jobs, although this is tradeoff obviously.<br>
><br>
> I'd be fine with this tradeoff if it allows us to keep PostgreSQL in the<br>
> mix.<br>
><br>
><br>
> Here is my proposed change to how we handle postgres in the gate:<br>
><br>
> <a href="https://review.openstack.org/#/c/100033" target="_blank">https://review.openstack.org/#/c/100033</a><br>
><br>
><br>
> Merge postgres and neutron jobs in integrated-gate template<br>
><br>
><br>
><br>
><br>
> Instead of having a separate job for postgres and neutron, combine them.<br>
> In the integrated-gate we will only test postgres+neutron and not<br>
><br>
><br>
> neutron/mysql or nova-network/postgres.<br>
><br>
> * neutron/mysql is still tested in integrated-gate-neutron<br>
> * nova-network/postgres is tested in nova<br>
<br>
</div></div>Because neutron only runs smoke jobs, this actually drops all the<br>
interesting testing of pg. The things I've actually seen catch<br>
differences are the nova negative tests, which basically aren't run in<br>
this job.<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So I think that's kind of the worst of all possible worlds, because it<br>
would make people think the thing is tested interestingly, when it's not.<br>
<div class="HOEnZb"><div class="h5"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>