I think having backup tables adds substantial systematic complexity, for a small use case.
Perhaps a better answer is to document in 'take a backup here' as part of the upgrade documentation and let sysadmins make a risk assessment. We can note that downgrades are not possible. Even in a public cloud doing trunk deploys, taking a backup shouldn't be a big deal: *those* situations are where you expect backups to be well understood; and small clouds don't have data scale issues to worry about. -Rob -Rob On 12 September 2013 17:09, Joshua Hesketh <[email protected]> wrote: > On 9/4/13 6:47 AM, Michael Still wrote: >> >> On Wed, Sep 4, 2013 at 1:54 AM, Vishvananda Ishaya >> <[email protected]> wrote: >>> >>> +1 I think we should be reconstructing data where we can, but keeping >>> track of >>> deleted data in a backup table so that we can restore it on a downgrade >>> seems >>> like overkill. >> >> I guess it comes down to use case... Do we honestly expect admins to >> regret and upgrade and downgrade instead of just restoring from >> backup? If so, then we need to have backup tables for the cases where >> we can't reconstruct the data (i.e. it was provided by users and >> therefore not something we can calculate). > > > So assuming we don't keep the data in some kind of backup state is there a > way we should be documenting which migrations are backwards incompatible? > Perhaps there should be different classifications for data-backwards > incompatible and schema incompatibilities. > > Having given it some more thought, I think I would like to see migrations > keep backups of obsolete data. I don't think it is unforeseeable that an > administrator would upgrade a test instance (or less likely, a production) > by accident or not realising their backups are corrupted, outdated or > invalid. Being able to roll back from this point could be quite useful. I > think potentially more useful than that though is that if somebody ever > needs to go back and look at some data that would otherwise be lost it is > still in the backup table. > > As such I think it might be good to see all migrations be downgradable > through the use of backup tables where necessary. To couple this I think it > would be good to have a standard for backup table naming and maybe schema > (similar to shadow tables) as well as an official list of backup tables in > the documentation stating which migration they were introduced and how to > expire them. > > In regards to the backup schema, it could be exactly the same as the table > being backed up (my preference) or the backup schema could contain just the > lost columns/changes. > > In regards to the name, I quite like "backup_table-name_migration_214". The > backup table name could also contain a description of what is backed up (for > example, 'uuid_column'). > > In terms of expiry they could be dropped after a certain release/version or > left to the administrator to clear out similar to shadow tables. > > Thoughts? > > Cheers, > Josh > > -- > Rackspace Australia > >> >> Michael >> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
