Open Stack

On Fri, Nov 01, 2013, Sean Dague <sean at dague.net> wrote:
> It's trading one source of bugs for another. I'd love to say we can
> have our cake and eat it to, but we really can't. And I very much
> fall on the side of "getting migrations is hard, updating past
> migrations without ever forking the universe is really really hard,
> and we've completely screwed it up in the past, so lets not do it."

I understand what you're saying, but if the result of it is that we're
never going to touch old migrations, we're going to slowly build
technical debt.

I don't think it's an acceptable solution to throw up our hands and deal
with the pain.

We need to come up with a solution that allows us to stay agile while
also ensuring we don't break things.

> So I'm going to call a straight BS on that. In at least one of the
> cases columns were shortened from 256 to 255. In the average case
> would that be an issue? Probably not. However that's a truncation,
> and a completely working system at 256 length for those fields could
> go to non working with data truncation. Data loads matter. And we
> can't assume anything about the data in those fields that isn't
> enforced by the DB schema itself.

I assume this is the review you're talking about?

https://review.openstack.org/#/c/53471/3

FWIW, the old migrations *are* functionally identical. Those strings are
still 256 characters long.

It's the new migration that truncates data.

That said, I'm not sure I see the value in this particular cleanup
considering the fact it does truncate data (even if it's unlikely to
cause problems).

> I've watched us mess this up multiple times in the past when we were
> *sure* it was good. And as has been noticed recently, one of the
> collapses changes a fk name (by accident), which broke upgrades to
> havana for a whole class of people.
> 
> So I think that we really should put a moratorium on touching past
> migrations until there is some sort of automatic validation that the
> new and old path are the same, with sufficiently complicated data
> that pushes the limits of those fields.
> 
> Manual inspection by one person that their environment looks fine
> has never been a sufficient threshold for merging code.

I can get completely on board with that.

Does that mean you're softening your stance that migrations should never
be touched?

JE