On Fri, Nov 01, 2013, Sean Dague <s...@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 _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev