As features make it into the Chef Server it has become obvious that we need a better way to handle data and API changes in ec-backup based on the version of the Chef Server the backup was made from.
For example, a backup of a Chef Server version 12.1.0 will have subtle differences that a backup made of a 12.15.x server. A restore of the 12.1.0 backup to a current Chef Server release will need certain corrective behavior in order to restore in a way that handles all of the differences in the current releases. A specific example is the renaming of the ORG_global_admins to ::brewinc_read_access_group and the addition of the ::server-admins group.
If we save a VERSION file with the knife-ec-backup backup archive, we can then utilize that file to determine the version of the Chef Server the backup was made from and the version of knife-ec-backup that was used.
Knowing those versions, we can then create a cleaner implementation to handle data modification during a restore.
As features make it into the Chef Server it has become obvious that we need a better way to handle data and API changes in ec-backup based on the version of the Chef Server the backup was made from.
For example, a backup of a Chef Server version 12.1.0 will have subtle differences that a backup made of a 12.15.x server. A restore of the 12.1.0 backup to a current Chef Server release will need certain corrective behavior in order to restore in a way that handles all of the differences in the current releases. A specific example is the renaming of the
ORG_global_adminsto::brewinc_read_access_groupand the addition of the::server-adminsgroup.If we save a
VERSIONfile with theknife-ec-backupbackup archive, we can then utilize that file to determine the version of the Chef Server the backup was made from and the version ofknife-ec-backupthat was used.Knowing those versions, we can then create a cleaner implementation to handle data modification during a restore.