feat(0013): Add initial version of configuration migration EIP

[zmstone]

It's great that you proposed to handle hop beam upgrade cases, which is a 'nice to have' feature. I'd propose to confine the scope with only table schema transformation.

During patch releases: For patch releases, we should avoid doing table schema changes, and for data changes, code will have to be backward compatible, i.e. no need to do table transformation. For configs, we'll have to write backward compatible schema (and perhaps code which makes use of the configs). i.e. no need to do config transformation

to sum up, the requirement is straightforward: provide a script which can:

• dump the database to a file, and also collect config files (optional, e.g. for k8s deployment, configs are usually managed outside)
• transform data (maybe schema too) to make it compatible with the new release

[k32]

@zmstone Thanks for the review, applied remarks

[zmstone]

For 5.0 to 5.1 upgrade, we may want to perform rolling upgrade for the cluster instead of upgrading the nodes into a different cluster. To meet this requirement, I wonder if it's possible at all to change Mnesia schema the way in this proposal.

[zmstone]

For 5.0 to 5.1 upgrade, we may want to perform rolling upgrade for the cluster instead of upgrading the nodes into a different cluster. To meet this requirement, I wonder if it's possible at all to change Mnesia schema the way in this proposal.

1. if we do mnesia:transform_table on the fly, do we still need the BUP (we may need BUP for backup/restore, but not necessary for upgrade purposes)?
2. mnesia:transform_table probably enables schema change for the core nodes, what about the replicant nodes ?