Open Stack

On Mon, Jun 16, 2014 at 11:38 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>
>
> On Sat, Jun 14, 2014 at 3:46 AM, Sean Dague <sean at dague.net> wrote:
>>
>> On 06/13/2014 06:47 PM, Joe Gordon wrote:
>> >
>> >
>> >
>> > On Thu, Jun 12, 2014 at 7:18 PM, Dan Prince <dprince at redhat.com
>> > <mailto: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
>> >     <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'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 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
>