Open Stack

On 02/01/2017 09:12 AM, Matt Riedemann wrote:
> On 2/1/2017 8:07 AM, Julien Danjou wrote:
>> Hi there,
>>
>> So the Ceilometer gate has been broken again by Nova today because of a
>> SQL bug in the placement API with PostgreSQL. This is the second time
>> that something like that happened: last November¹, we also reported a
>> bug in Nova wrt PostgreSQL.
>>
>> Fortunately, Mehdi investigated and sent a fix:
>>
>>   https://review.openstack.org/#/c/427667/
>>
>> So the issue is going to be resolved soon. I had hope this would not
>> happen again, but it seems Nova does not care about PostgreSQL since
>> August².
>>
>> I think I can understand that Nova does not want to support PostgreSQL
>> and therefore does not use it in the gate, however, I don't think it's a
>> rich idea to have other projects (e.g. Ceilometer) doing the gate check
>> for Nova.
>>
>> My questions are simple and can be organized in a tree:
>>
>>            Does Nova want to support PostgreSQL?
>>                  /                      \
>>                Yes                      No
>>                /                          \
>>    Why is there no gate?         Ok, we'll have to remove the
>>                                  PostgreSQL job in Ceilometer
>>
>>
>> Thanks!
>>
>>
>> ¹ 
>> http://lists.openstack.org/pipermail/openstack-dev/2016-November/107907.html
>>
>>
>> ² 
>> http://lists.openstack.org/pipermail/openstack-dev/2016-August/101892.html
>>
>>
>>
>>
>> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> It's not just Nova, it's the entire set of integrated-gate jobs which
> dropped the postgresql job. There is a bit more history there, it's in
> the ML somewhere, but it's not just like Nova decided to stop running it
> in the integrated gate.

Yah. Postgres support has historically been one of those things that
occasionally someone says "we should support postgres" - and then
consistently it breaks and nobody cares enough to fix it.

> At the time it was removed, I said I thought it might be a good idea to
> run it on oslo.db changes, or at least in a periodic job queue, but
> since we removed it from the integrated-gate set of jobs I wouldn't just
> make it gating by itself on nova again.
> 
> If it could be worked into an existing job as a wrinkle then that's an
> option, i.e. nova has this placement job which was unique in newton
> because it ran the optional things at the time for nova like placement
> and cells v2, but those are required globally now in master so are less
> special. But in Pike we're going to be looking at some new snowflakes
> for that job, like cinder v3, service users, etc etc, so maybe postgres
> could be worked in there.

I personally continue to be of the opinion that without an explicit
vocal and well-staffed champion, supporting postgres is more trouble
than it is worth. The vast majority of OpenStack deployments are on
MySQL - and what's more, the code is written with MySQL in mind.
Postgres and MySQL have different trade offs, different things each are
good at and different places in which each has weakness. By attempting
to support Postgres AND MySQL, we prevent ourselves from focusing
adequate attention on making sure that our support for one of them is
top-notch and in keeping with best practices for that database.

So let me state my opinion slightly differently. I think we should
support one and only one RDBMS backend for OpenStack, and we should open
ourselves up to use advanced techniques for that backend. I don't
actually care whether that DB is MySQL or Postgres - but the corpus of
existing deployments on MySQL and the existing gate jobs I think make
the choice one way or the other simple.

I agree that ceilometer should not be providing Postgres testing for the
rest of OpenStack.

Monty