This adds a new command `rkt rmimage` to remove one or more images from the
store providing a key uniquely resolvable.
The logic is to firstly remove transactional data (the rows in the aciinfo and
remote db tables for the given key) and then remove non transactional data (the
diskv blob and imageManifest stores).
The tree store is removed separately and only if an image hash related to the
tree store key isn't referenced by any preparing/prepared/running pod.
This means that an image can be removed (from the db and the blob/imageManifest
stores) but not from the treestore.
As removal of non transactional data can fail for multiple reasons some data
can remain stale, the same applies if the treestore can't be removed because
referenced by a pod.
A future patch will provide a cas gc to clean the stale files and unreferenced
treestores.
Example:
```
$ rkt rmimage sha512-aa244c542b1b631bbd616bc266909b sha512-aaa wronghash
rkt: successfully removed aci for key: "sha512-aa244c542b1b631bbd616bc266909b"
rkt: key "sha512-aaa" not valid: no keys found
rkt: wrong key "wronghash": badly formatted hash string
rkt: 1 image(s) successfully removed
rkt: 2 image(s) cannot be removed
```
This adds a new command "rkt images" to display the images in the store.
The -fields option let the user provide a comma separated list of fields to display. Accepted values: "key", "appname", "importtime", "latest".
The -sort option permits to sort the output according to the provided comma separated list of fields. Accepted values: "appname", "importtime".
The ordering is ascending by default but can be configured with the -order=[asc|desc] option.
By default all the available fields ("key", "appname", "importtime", "latest") are displayed sorted by ascending "importtime".
If the image has a version label its written in the app name (with the ":$version" format).
In future additional options can be provided:
* show all the labels
* define displayed time format (for example human format like "3 days ago").
* filter by field value.
Examples:
```
$ rkt images
KEY APPNAME IMPORTTIME LATEST
sha512-fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df coreos.com/etcd:v2.0.5 2015-03-01 16:18:38.951 +0100 CET false
sha512-683438b100a48aead6c37e4f581105713763bb41c3f995ad58a2cc49eb744d68 test 2015-03-01 16:53:47.45 +0100 CET false
sha512-8cf2956f26035ac7d34b78722b8a738fae74acfe29b18db0a92ed44bbcfd2958 coreos.com/rocket/stage1:0.0.1 2015-03-01 17:02:34.636 +0100 CET false
sha512-d6bb5eb2c30cd12d305192c395f783d7039136a7484f2e07761323a39a0915b6 coreos.com/rocket/stage1:0.0.1 2015-03-10 12:03:26.57 +0100 CET false
```
```
$ rkt images -sort="appname,importtime" -order=desc -fields="importtime,appname,latest"
IMPORTTIME APPNAME LATEST
2015-03-01 16:53:47.45 +0100 CET test false
2015-03-10 12:03:26.57 +0100 CET coreos.com/rocket/stage1:0.0.1 false
2015-03-01 17:02:34.636 +0100 CET coreos.com/rocket/stage1:0.0.1 false
2015-03-01 16:18:38.951 +0100 CET coreos.com/etcd:v2.0.5 false
```
Create all cas directories explicitly and create qldb files with the
right permissions.
If we don't create them and the first fetch is made by root, the
files/directories will be created with root permissions and following
fetches as a user belonging to the rkt group will fail.
This patch adds migrate codes and tests. It simply updates the current db
version to 1 without changing the schema.
The migration needs an exclusive store lock to avoid concurrent old rkt versions
operating to an updated db and returning strange errors or giving bad behaviours.
As the store lock is removed when spawning the stage0, migration isn't blocked by
running containers but only by rkt processes doing store operations (like
downloading an image, rendering an aci etc...).
Now migration covers only db updates. If the migration needs to also operate on
the other "non transactional" store entities (like the diskv stores or the tree
store) this should be thoroughly reasoned, as a rollback in case of an error is
not an easy task.
Test are added to introduce the migration testing framework and be the base for
future migration tests.
Actually if a panic in a called function happens, the deferred function will
call tx.Commit (as on panic err is nil), with the possibility to commit an
incomplete transaction, instead of rollbacking or returning an error (that will
rolback on the next db.Close).
One solution will be to recover the panic to avoid calling tx.Commit.
As the error path is only one, just call tx.Rollback/tx.Commit in the proper
places without using a deferred function.
Jonathan Boulle