Conary:Fencing Old Rollbacks
From rPath Wiki
| Conary Developer Community | Go to the community main page |
|
Fencing Old Rollbacks
Issue: CNY-851
Summary: ability to prevent people from rolling back to previous versions of packages (or re-installing old packages) if there is state outside of the Conary database that would prevent the code from running.
Terminology
- Application state: a version string representing the format of the data handled by the application's code. Note that one can have new application code handle an old data format, and thus the versioning of the two has to be decoupled. Also, there is a moment in time when upgrading the application means new code with old data.
Use cases
Generic use cases
- User installs package foo which deploys a database.
- User upgrades package foo to a newer version which changes the database format (and has scripts to convert from the old format to the new one).
- User decides to roll back (using Conary) to the previous version, after the conversion script was run. Unfortunately, the old code does not understand the new database format.
- Alternative case is for the user to try to manually downgrade using Conary.
Specific use cases
- Conary - Conary database format
- rBuilder
- Application (or appliance) using PostgreSQL as data store, upgrading to a newer version of Postgres.
Possible solutions
We need to represent the state of the application in the Conary database, but not update it as part of code updates. The conversion script will have to change the state in the Conary database upon successful completion.
| Package version | Ability to convert: script(state1, state2)
| Native application state |
|---|---|---|
| A | 1 | |
| B | s1(1, 2) | 2 |
| C | s2(2, 3) s3(3, 2) | 3 |
This provides Conary with an interesting digraph model that allows one to infer if they can safely move from the current state to another, what possible backup scenarios they have etc.
We could use file stream attributes to represent the application state and flag the scripts that have the ability to convert the state from one version to another.
Using Conary as an example:
| File | Attribute |
|---|---|
/var/lib/conarydb/conarydb
| dbver=2
|
/usr/libexec/conary/cvt1
| conaryconvert(dbver=1, dbver=3) conaryconvert(dbver=2, dbver=3)
|
/usr/libexec/conary/rbk1
| conaryconvert(dbver=3, dbver=2
|
If execution of cvt1 finished successfully, the attribute for /var/lib/conarydb/conarydb should be updated to dbver=3.
Prerequisites
Erik mentioned there are some problems in adding new information to files. To be expanded.
Misa 19:37, 12 January 2007 (EST)