-
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
Migration: update system integration #91
Comments
Sample migration metadata in some TUF-signed metadata file in repo:
(That's a "from" version, a "to" version, and list of migrations filenames. The migration filenames are listed in Or, instead of a tuple, could be a nested mapping, with the "from" version at the outside, and (potentially multiple) "to" versions on the inside. The idea of allowing multiple "to" versions (in either format) is if we want to allow for migrations to make bigger jumps between versions for efficiency. Either way, we do need the "from" and "to" versions, rather than walking through versions, because there's no way to know what version was before "1.0", for example. |
Hmm, what I'm planning on doing in tough doesn't take into account downgrades where the older partition has an older root.json. For example, if v0.4.2 is released with root.json version 3, and a downgrade is requested to v0.4.1 with root.json version 1, the cached repository metadata wouldn't include root.json version 2. I think updog will need to know the version of root.json present in an image, which may be a more general "can we associate arbitrary metadata with an image version" question. |
Spoke with @bcressey and we think we can work around the rollback issue by downloading all versions of root.json, which we can do without even making any changes to tough (although the "fetch this version of root.json" method might be worth including in tough). |
Before rebooting for an update:
The text was updated successfully, but these errors were encountered: