Open Stack

After some discussion with folks in the infra team the other day, we've 
come up with the following plan of attack.

Postgresql is currently failing the gate, we've turned it non voting. 
We're going to see if anyone's interested enough in working on fixing it.

If we're still broken on the gate in 2 weeks, and no one is making 
progress on fixing it, we're going to just pull it from the gate.

So if you care about keeping postgresql in the gate, please step up. 
Some nova fixes will be needed.

	-Sean

On 04/23/2013 11:03 AM, Sean Dague wrote:
> Clark and I discovered yesterday that Postgresql is no longer running in
> the gate. Turns out a set of subtle changes over in devstack & devstack
> gate meant we weren't setting things correctly, so we've been running
> for a couple of weeks without postgresql.
>
> On the plus side we didn't break any previous tempest tests. On the down
> side, we merged a few more tempest negative tests that generate stack
> traces in Postgresql because we very often send bad data all the way
> down to the database.
>
> MySQL happily will put anything in a where clause (regardless of type,
> size, smelliness), and return "not found". Postgresql is actually typed,
> and throws a DataError if you try to use string as an int, or too long
> of an int as and int. When we fixed this for get_instance(id) we added
> catching the DataError in the SQLA layer, translating to an InvalidID to
> pass it to the request layer, where it gets turned into a NotFound for
> the user.
>
> Now that we're seeing it in another couple of places, we should probably
> think about more systematic ways to go about this.
>
> Also, if Postgresql is really important to someone, we really do need a
> champion on it that's going to aggressively be trying to expose these
> issues. There are some quick fixes (more DataError -> InvalidID
> catches), but the right answer is probably a more systemic approach
> about preventing these kinds of requests to get down to the lower layers
> at all.
>
> But, this still needs a champion and a doer to get us there. I was that
> for Grizzly to prove it was doable, and clean out a set of issues, but
> for Havana this is pretty low priority for me, so someone else is really
> needed here to keep postgresql functioning in the gate.
>
>      -Sean
>


-- 
Sean Dague
http://dague.net