v0.5.5

rkt 0.5.5 includes a move to cni network plugins, a number of minor bug fixes and two new experimental commands for handling images: rkt images and rkt rmimage. An example session of using these commands follows. These two new commands will once we fully settle on sub command namings #649.

$ rkt images
KEY                                 APPNAME             IMPORTTIME              LATEST
sha512-91e98d7f1679a097c878203c9659f2a26ae394656b3147963324c61fa3832f15 coreos.com/etcd:v2.0.9      2015-05-01 19:20:27.511 -0400 EDT   false
sha512-782ff95658a3412b17f164a9422d88882c2417a51b06302ecefc83eab093a383 coreos.com/rkt/stage1:0.0.1 2015-05-01 19:24:10.367 -0400 EDT   false
$ rkt rmimage sha512-91e98d7f1679a097c878203c9659f2a26ae394656b3147963324c61fa3832f15
rkt: successfully removed aci for imageID: "sha512-91e98d7f1679a097c878203c9659f2a26ae394656b3147963324c61fa3832f15"
rkt: 1 image(s) successfully removed

Full changelog:

• switched to using cni based network plugins
• fetch images dependencies recursively when ACIs have dependent images
• fix the progress bar used when downloading images with no content-length
• building the initial stage1 can now be done on various versions of systemd
• support retrying signature downloads in the case of a 202
• remove race in doing a rkt enter
• various documentation fixes to getting started and other guides
• improvements to the functional testing using a new gexpect, testing for non-root apps, run context, port test, and more

v0.5.4

rkt 0.5.4 introduces a number of new features - repository authentication, per-app arguments + local image signature verification, port forwarding and more. Further, although we aren't yet guaranteeing API/ABI stability between releases, we have added important work towards this goal including functional testing and database migration code.

This release also sees the removal of the --spawn-metadata-svc flag to rkt run. The flag was originally provided as a convenience, making it easy for users to get started with the metadata service. In rkt v0.5.4 we removed it in favor of explicitly starting it via rkt metadata-service command. For more details on running the metadata service - including example unit files for use with systemd - check out the documentation.

Full changelog:
- added configuration support for repository authentication (HTTP Basic Auth, O Auth, and Docker repositories). Full details in Documentation/configuration.md
- rkt run now supports per-app arguments and per-image --signature specifications
- rkt run and rkt fetch will now verify signatures for local image files
- rkt run with --private-net now supports port forwarding (using --port=NAME:1234)
- rkt run now supports a --local flag to use only local images (i.e. no discovery or remote image retrieval will be performed)
- added initial support for running directly from a pod manifest
- the store DB now supports migrations for future versions
- systemd-nspawn machine names are now set to pod UUID
- removed the --spawn-metadata-svc option from rkt run; this mode was inherently racy and really only for convenience. A separate rkt metadata-service invocation should be used instead.
- various internal codebase refactoring: "cas" renamed to "store", tasks to encapsulate image fetch operations, etc
- bumped docker2aci to support authentication for Docker registries and fix a bug when retrieving images from Google Container Registry
- fixed a bug where --interactive did not work with arguments
- garbage collection for networking is now embedded in the stage1 image
- when rendering images into the treestore, a global syncfs() is used instead of a per-file sync(). This should significantly improve performance when first extracting large images
- added extensive functional testing on semaphoreci.com/coreos/rkt
- added a test-auth-server to facilitate testing of fetching images

v0.5.3

This release contains minor updates over v0.5.2, notably finalising the move to pods in the latest appc spec and becoming completely name consistent on rkt.

• {Container,container} changed globally to {Pod,pod}
• {Rocket,rocket} changed globally to rkt
• rkt install properly sets permissions for all directories
• rkt fetch leverages the cas.Store TmpDir/TmpFile functions (now exported) to generate temporary files for downloads
• Pod lifecycle states are now exported for use by other packages
• Metadata service properly synchronizes access to pod state

v0.5.2

This release is a minor update over v0.5.1, incorporating several bug fixes and a couple of small new features:

• rkt enter works when overlayfs is not available
• rkt run now supports the --no-overlay option referenced (but not implemented!) in the previous release
• the appc-specified environment variables (PATH, HOME, etc) are once again set correctly during rkt run
• metadata-service no longer manipulates IP tables rules as it connects over a unix socket by default
• pkg/lock has been improved to also support regular (non-directory) files
• images in the cas are now locked at runtime (as described in #460)

v0.5.1

This release updates Rocket to follow the latest version of the appc spec, v0.5.1. This involves the major change of moving to pods and Pod Manifests (which enhance and supplant the previous Container Runtime Manifest). The Rocket codebase has been updated across the board to reflect the schema/spec change, as well as changing various terminology in other human-readable places: for example, the previous ambiguous (unqualified) "container" is now replaced everywhere with "pod".

This release also introduces a number of key features and minor changes:

• overlayfs support, enabled for rkt run by default (disable with --no-overlayfs)
• to facilitate overlayfs, the CAS now features a tree store which stores expanded versions of images
• the default stage1 (based on systemd) can now be built from source, instead of only derived from an existing binary distribution as previously. This is configurable using the new .RKT_STAGE1_USR_FROM environment variable when invoking the build script - see fdcd649
• the metadata service now uses a Unix socket for registration; this limits who can register/unregister pods by leveraging filesystem permissions on the socket
• rkt list now abbreviates UUIDs by default (configurable with --full)
• the ImageManifest's readOnly field (for volume mounts) is now overridden by the rkt command line
• a simple debug script (in scripts/debug) to facilitate easier debugging of applications running under Rocket by injecting Busybox into the pod
• documentation for the metadata service, as well as example systemd unit files

v0.4.2

• First support for interactive containers, with the rkt run --interactive flag. This is currently only supported if a container has one app. #562 #601
• Add container IP address information to rkt list
• Provide /sys and /dev/shm to apps (per spec)
• Introduce "latest" pattern handling for local image index
• Implement FIFO support in tar package
• Restore atime and mtime during tar extraction
• Bump docker2aci dependency

v0.4.1

This is primarily a bug fix release with the addition of the rkt install subcommand to help people setup a unprivileged rkt fetch based on unix users.

• Fix marshalling error when running containers with resource isolators
• Fixup help text on run/prepare about volumes
• Fixup permissions in rkt trust created files
• Introduce the rkt install subcommand

v0.4.0

This release is mostly a milestone release and syncs up with the latest release of the appc spec yesterday.

Note that due to the introduction of a database for indexing the local CAS, users upgrading from previous versions of Rocket on a system may need to clear their local cache by removing the cas directory. For example, using the standard Rocket setup, this would be accomplished with rm -fr /var/lib/rkt/cas.

Major changes since v0.3.2:

• Updated to v0.4.0 of the appc spec
• Introduced a database for indexing local images in the CAS (based on github.com/cznic/ql)
• Refactored container lifecycle to support a new "prepared" state, to pre-allocate a container UUID without immediately running the application
• Added support for passing arguments to apps through the rkt run CLI
• Implemented ACI rendering for dependencies
• Renamed rkt metadatasvc -> rkt metadata-service
• Added documentation around networking, container lifecycle, and rkt commands

v0.3.2

This release introduces much improved documentation and a few new features.

The highlight of this release is that Rocket can now natively run Docker images. To do this, it leverages the appc/docker2aci library which performs a straightforward conversion betwen images in the Docker format and the appc format.

A simple example:

$ rkt --insecure-skip-verify run docker://redis docker://tenstartups/redis-commander
rkt: fetching image from docker://redis
rkt: warning: signature verification has been disabled
Downloading layer: 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158
...

Note that since Docker images do not support image signature verification, the -insecure-skip-verify must be used.

Another important change in this release is that the default location for the stage1 image used by rkt run can now be set at build time, by setting the RKT_STAGE1_IMAGE environment variable when invoking the build script. (If this is not set, rkt run will continue with its previous behaviour of looking for a stage1.aci in the same directory as the binary itself. This makes it easier for distributions to package Rocket and include the stage1 wherever they choose (for example, /usr/lib/rkt/stage1.aci). For more information, see #520

v0.3.1

The primary motivation for this release is to resynchronise versions with the appc spec. To minimise confusion in the short term we intend to keep the major/minor version of Rocket aligned with the version of spec it implements; hence, since yesterday v0.3.0 of the appc spec was released, today Rocket becomes v0.3.1. After the spec (and Rocket) reach v1.0.0, we may relax this restriction.

This release also resolves an upstream bug in the appc discovery code which was causing rkt trust to fail in certain cases.