Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove data store version #760

Merged
merged 3 commits into from
Feb 21, 2020
Merged

Remove data store version #760

merged 3 commits into from
Feb 21, 2020

Commits on Feb 21, 2020

  1. Fix type in RemoveSettingMigration so we don't need to copy strings

    @tjkirch
    tjkirch committed Feb 21, 2020
    Configuration menu
    Copy the full SHA
    752d497 View commit details
    Browse the repository at this point in the history

  2. apiserver: don't fail list_transactions if '/pending' doesn't exist

    @tjkirch
    tjkirch committed Feb 21, 2020
    Configuration menu
    Copy the full SHA
    cac0bc9 View commit details
    Browse the repository at this point in the history

  3. Remove data store version, use OS version instead 

    We found confusion between data store versions and OS versions, so this
simplifies the system to only use OS version.  If there's been no change in the
data store, which is now determined by there being no migrations, then the new
data store will simply be a link to the last version that did have changes.

These are the changes at a high level:
* Remove the data_store_version library and its type, instead using semver::Version
  * Cascade this change through migrator, storewolf, update_metadata, and updog
* Remove OS version -> data store version mapping in updog
* Remove the data-store-version file, instead using OS version from bottlerocket-release
* In migrator, just symlink to previous data store if there are no migrations
* In migrator, flip symlinks for current, major, minor, and patch, since any could change
* In storewolf, also create the new patch-level symlink

One change deserves more description.  It's an extension of the problem from #644
that only showed up while testing this change, and was made easier to fix by
these changes, so it was done together.

Background: In migrator, we were giving each migration the same source and
target data store.  Migrations make whatever changes they want to a
MigrationData, each key of which is then written to the data store.

Problem: Let's say the system has settings A and B.  One migration adds setting
C.  This is written to the target data store.  Another migration tries to
remove setting B.  It does so in memory, but B has already been written to the
target by the first migration, so it's to no avail.

Solution: Chain the input and output of migrations in order.  The first
migration receives the source data store and adds setting C, writing out to a
*new* data store path it was given.  The second migration is given that new
data store as a source; it removes setting B and writes out to another new data
store path it was given.  At the end of the chain, the final data store is kept
and the intermediate ones are removed.
    @tjkirch
    tjkirch committed Feb 21, 2020
    Configuration menu
    Copy the full SHA
    f8a95cf View commit details
    Browse the repository at this point in the history