Open Stack

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 <joshua.hesketh at rackspace.com> wrote:
> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud