Open Stack

On 9/4/13 6:47 AM, Michael Still wrote:
> On Wed, Sep 4, 2013 at 1:54 AM, Vishvananda Ishaya
> <vishvananda at gmail.com> 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
>