Open Stack

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 <akamyshnikova at mirantis.com> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140522/77674841/attachment.html>