-
Notifications
You must be signed in to change notification settings - Fork 519
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.
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
updog and migrator: signed migrations #930
Conversation
...itory/targets/e823375105cd38d5e0476a4e277bc61eef3c15bd0d8831e2f78bc9394b4f1335.manifest.json
Outdated
Show resolved
Hide resolved
...itory/targets/e823375105cd38d5e0476a4e277bc61eef3c15bd0d8831e2f78bc9394b4f1335.manifest.json
Outdated
Show resolved
Hide resolved
sources/api/migration/migrator/tests/data/repository/metadata/timestamp.json
Outdated
Show resolved
Hide resolved
push to 3f62781 uses |
sources/api/migration/migrator/tests/data/repository/targets/a-second-migration.sh
Outdated
Show resolved
Hide resolved
sources/api/migration/migrator/tests/data/repository/targets/a-second-migration.sh
Outdated
Show resolved
Hide resolved
sources/api/migration/migrator/tests/data/repository/metadata/timestamp.json
Outdated
Show resolved
Hide resolved
sources/api/migration/migrator/tests/data/repository/metadata/1.root.json
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hoping @iliana can confirm the tempdir for tough datastore is OK.
@webern confirmed for me that this force-push ^ was just a rebase. |
This adds backward compatibility with unsigned migrations. |
This is a rebase from develop that bumps the version of |
This push addresses:
|
Small: cleanup in |
Small cleanups. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Added |
Addresses Ben's comments. |
Addresses iliana's smaller comments. |
Fix a one word oops. |
// unsigned migrations code and return. | ||
if !are_migrations_signed(¤t_version) { | ||
// note in the system journal that the unsigned code path ran. | ||
eprintln!("migrator is running unsigned migrations"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tjkirch left a comment here that, inexplicably, GitHub allowed me to delete when I was, in fact, trying to delete my own response. Fortunately I have both pasted to a text file:
@tjkirch wrote:
I don't think we need these messages in the logs/journal, we know which type of migrations ran based on the version. (Ties with my other comments about simplifying/removing the branching.)
And I replied:
I am using them during test cycles. I can delete them, but once I do I will no longer be able to verify correctness during the test cycles as I have been (see the test procedure in the PR comments).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to use a more structured method like running different migrations on each path. I'm hoping we can go back to the shell script method so having test migrations is trivial...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant when I run Bottlerocket and check the logs to ensure that migrator did what I want. However, I can remove these print statements as the last push.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was suggesting that we use different test migrations (which can print different output) to get the same effect, and even check it in the test, rather than impacting the actual codebase here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quickfixes for some of @tjkirch's comments. Not done yet... |
Uses |
I removed the large end-to-end migrator 'unit' test. I will try to introduce it in a future PR where we can spend more time refining it. |
Addresses most of @tjkirch's remaining comments. |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No more blockers from me, as long as testing is still good.
Just did a successful test cycle with b6fe3cd |
Issue number:
Closes #91
Closes #905
Description of changes:
Implements all changes necessary for migrator to load a locally cached tuf repo and obtain migrations from there. See #905 for a detailed explanation of the aigned migrations design.
Additionally, we decided to maintain compatibility so that instances can be upgraded into signed migrations. To facilitate this, in the current version,
upog
writes both signed and unsigned migrations.migrator
checks the from version. If it's less than0.3.5
, migrator executes unsigned migrations, otherwise it executes signed migrations.In a future version, we can create a breaking change in which unsigned migrations are no-longer read. At that point, versions less than 0.3.5 must pass through a version that supports both signed and unsigned migrations (such as this one) in order to upgrade into signed migrations.
There is one behavioral change about signed migrations. Previously we used a
sort
of the migration names to provide stability to their order of execution (when more than one migration existed for a single version pair). With signed migrations, this is no longer necessary and the migrations will run in the order that they are listed in the manifest.Testing done:
The testing procedure is extensive. Note: a trace was added so that
migrator
announces in the system journal whether it is running signed or unsigned migrations. Also note, v0.3.1 was used as a starting point because a migration exists for v0.3.2 (which changes the host container version). Thus upgrading from v0.3.1 presents an actual unsigned migration.Test Setup
root.json
.root.json
and add them to a TUF repo (replacing the prod images).foo
setting and sets its value tobar
. Call this v0.99.1 and add it to the TUF repo/manifest.Test Execution
Starting from the v0.3.1 AMI, perform the following sequence of upgrades and downgrades.
At each step along the way.
At the end of the cycle, diff the system journals to observe that migrator annouced:
Diff the API settings to observe the following setting changes:
Additional Testing
Additional testing has been performed with v0.99.0 AMI -> v0.99.1 -> v0.99.0, though this has not been repeated at every testing cycle.
TODO
pentacle
tough::RepoEditor
to create themigrator
unit test repo on the fly. (pushed)Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.