I think this is roughly the right approach - I've indeed already supportive on it in previous reviews/email discussions.
Conceptually, it is tantamount to adding an healing migration - which has the important characteristic of being idempotent. One problem with it is that it won't work with offline migrations; "healing" migrations might be skipped when running in offline mode, but there won't be the possibility of having an offline script for fixing a DB, However this might be a non-issue once we assess how important it would be to support offline migrations. >From the pod discussion etherpad however it seems this solution was deemed too complex - and the consensus is to develop scripts which will need to be run upon upgrade; while I understand this will lead to an easier solution from the development perspective, it will also put the onus on the operator, which will need to perform ad-hoc upgrade operations. Unless there are issues I'm not seeing at the moment, I think Anna is proving a few good points here: 1) DB healing can be performed within the migration framework 2) downgrades can be a simple no-op without breaking the consistency of the database I would also like to add that we might still use this as a chance to clear our migration path completely, removing the configuration-dependent logic, and providing a new migration for downgrading from icehouse to havana; I don't think there is anymore a reason for keeping a path that stretches back to folsom. Some pseudo-graphical details are available here: http://paste.openstack.org/show/81109/ Regards, Salvatore On 20 May 2014 09:13, Anna Kamyshnikova <[email protected]> wrote: > Hello everyone! > > Earlier topic of unconditional migrations was discussed in emails by me > and Salvatore. On summit there was a small meeting on which was discussed > this topic and some others. I haven't participated in this meeting but > member of my team Eugene was there instead of me and told me what was > decided to do. > > The idea is to create some methods that will check current table state: > - if it exists or not > - if all necessary changes have been made or not. > (All changes are checked from the very beginning till Icehouse) > > I was inspired of this idea and make some notes about that. They are shown > there > https://docs.google.com/document/d/10p6JKIQf_rymBuNeOywjHiv53cRTfz5kBg8LeUCeykI/edit?usp=sharingand > a test change that will show how this is going to work > https://review.openstack.org/93690. > > The organizer of all this work is Henry Gessau. Now he is working on bp on > this topic. > > I look forward to any comments about my notes and my test changes. > > Regards, > Ann > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
