Version 0.3.2-RC5 (2016-02-25)

Fixes

• Fixes regression in 0.3.2 RC3/RC4 resulting in no log file #319
• Fixes no volumes returned on empty list #322
• Fixes "Unsupported FS" when mounting/unmounting with EC2 #321

Documentation

Please see the v0.3.2-RC5 documentation for more information.

Version 0.3.2-RC4 (2016-02-24)

Enhancements

• ScaleIO volume name limitation #304
• Docker cache volumes for path operations #306
• Config file validation #312
• Better logging #296

Bug Fixes

• ScaleIO re-authentication issue #303
• Docker XtremIO create volume issue #307
• Service status is reported correctly #310

Updates

• Go 1.6 #308

Documentation

Please see the v0.3.2-RC4 documentation for more information.

Version 0.3.2-RC3 (2016-02-23)

Enhancements

• ScaleIO volume name limitation #304
• Docker cache volumes for path operations #306
• Config file validation #312
• Better logging #296

Bug Fixes

• ScaleIO re-authentication issue #303
• Docker XtremIO create volume issue #307
• Service status is reported correctly #310

Updates

• Go 1.6 #308

Documentation

Please see the v0.3.2-RC3 documentation for more information.

Version 0.3.2-RC2 (2016-02-05)

New Features

• Support for Docker 1.10 and Volume Plugin Interface 1.2 (#273)
• Stale PID File Prevents Service Start (#258)
• Module/Personality Support (#275)
• Isilon Preemption (#231)
• Isilon Snapshots (#260)
• boot2Docker Support (#263)
• ScaleIO Dynamic Storage Pool Support (#267)

Enhancements

• Documentation Updates (#285)

Documentation

Please see the v0.3.2-RC2 documentation for more information.

Thank You

• Dan Forrest
• Kapil Jain
• Alex Kamalov

Version 0.3.1 (2015-12-30)

New Features

• Support for VirtualBox (#209)
• Added Developer's Guide (#226)

Enhancements

• Mount/Unmount Accounting (#212)
• Support for Sub-Path Volume Mounts / Permissions (#215)

Milestone Issues

This release also includes many other small enhancements and bug fixes. For a
complete list click here.

Downloads

Click here for the 0.3.1
binaries.

Release 0.3.0

New Features

• Pre-Emption support (#190)
• Support for VMAX (#197)
• Support for Isilon (#198)
• Support for Google Compute Engine (GCE) (#194)

Enhancements

• Added driver example configurations (#201)
• New configuration file format (#188)

Tweaks

• Chopped flags --rexrayLogLevel becomes logLevel (#196)

Pre-Emption Support

Pre-Emption is an important feature when using persistent volumes and container schedulers. Without pre-emption, the default behavior of the storage drivers is to deny the attaching operation if the volume is already mounted elsewhere. If it is desired that a host should be able to pre-empt from other hosts, then this feature can be used to enable any host to pre-empt from another.

Milestone Issues

This release also includes many other small enhancements and bug fixes. For a complete list click here.

Downloads

Click here for the 0.3.0 binaries.

REX-Ray 0.2.1

New Features

• Support for OpenStack (#111)
• Create volume from volume using existing settings (#129)

Enhancements

• A+ GoReport Card
• A+ Code Coverage
• GoDoc Support
• Ability to load REX-Ray as an independent storage platform (#127)
• New documentation at http://rexray.readthedocs.org (#145)
• More foundation updates

Tweaks

• Command aliases for get and delete - ls and rm (#107)

REX-Ray 0.2.1 Release Candidate 1

New Features

• Support for OpenStack (#111)
• Create volume from volume using existing settings (#129)

Enhancements

• A+ GoReport Card
• A+ Code Coverage
• GoDoc Support
• Ability to load REX-Ray as an independent storage platform (#127)
• New documentation at http://rexray.readthedocs.org (#145)
• More foundation updates

Tweaks

• Command aliases for get and delete - ls and rm (#107)

REX-Ray 0.2.0 Release Candidate 4 (RC4)

This release candidate contains the following changes:

• The stupid repository has been renamed to unstable
  *. A standard installation/uninstallation system has been created that is used regardless whether executed manually or by a package manager.
• Support for building and deploying RPM and DEB packages
• The REX-Ray binary may live wherever, but all of the data is created at the location defined by the environment variable REXRAY_HOME.
• When executed as a service REX-Ray logs to $REXRAY_HOME/var/log/rexray/rexray.log
• Other minor bugfixes, enhancements, etc...

Repositories

There's not much more to say but that the repository once known as stupid has been renamed to unstable. The old stupid links will continue to work for versions pushed to the repository when it was named such, but once the next release candidate is pushed, those versions will be purged.

Installer

The REX-Ray binary now supports the install and uninstall commands, executed as rexray install or rexray uninstall. These commands install the REX-Ray service if on a Linux system. Additionally, the install and uninstall commands are also what is used by the RPM and DEB packages, meaning that the REX-Ray installer is distribution and package agnostic.

Package Support

The Makefile now has support for the following targets:

• rpm
• rpm-all
• rpm-linux-amd64
• rpm-linux-386
• deb
• deb-all
• deb-linux-amd64

The above targets do what they imply they do -- they assemble the REX-Ray binary into an RPM or DEB package. Please note the above targets expect the appropriate architecture of REX-Ray to already be built and will not force a new build of REX-Ray.

Also, it's not without much trouble that building a 32-bit DEB package is possible on a 64-bit system, and thus the 32-bit DEB package is not available at this time. Since alien was used to create the DEB packages from the RPMS, the 32-bit RPM could easily be converted to a 32-bit DEB if a 32-bit Debian system were available.

The packages install REX-Ray and register its service, but the server is not started.

REXRAY_HOME

The REX-Ray binary can exist anywhere on a system, but when it is executed it assumes the following paths (and will create them if they do not exist):

• $REXRAY_HOME/etc/rexray
• $REXRAY_HOME/var/lib/rexray
• $REXRAY_HOME/var/log/rexray
• $REXRAY_HOME/var/run/rexray

If the REXRAY_HOME environment variable does not exist then the above paths will exist within the filesystem layout standard for both almost any UNIX-derived system such as Linux or Darwin (OS X).

However, defining REXRAY_HOME to be /opt/rexray/0.2.0 means that all four paths above will be created and expected to exist at /opt/rexray/0.2.0.

Again, the REX-Ray binary can reside in /usr/bin, /opt/rexray/0.2.0/usr/bin, at /, or anywhere on the filesystem. The binary's location is independent of where the data is stored.

Service Logging

When REX-Ray is executed as a service the logs are no longer emitted to stdout (except for SystemD where they are, but not limited to there). Instead the logs are written to $REXRAY_HOME/var/log/rexray/rexray.log.

Of note, when logs are emitted to stdout they are color-coded, but not so when written to a log file.

Release 0.2.0 RC1

The first release candidate for 0.2.0 introduces many improvements to the REX-ray tool at a core level in order to lower REX-ray's barrier of entry to bloggers, end-users, systems administrators, and software engineers.

All changes introduced by this commit should be considered breaking changes and updates to existing documentation is required.

Installation, SysV, SystemD Support

REX-ray now includes built-in support for installing itself as a service on Linux distributions that support either SystemV or SystemD initialization systems. This feature has been tested successfully on both CentOS 7 Minimal (SystemD) and Ubuntu 14.04 Server (SystemV) distributions.

To install REX-ray on a supported Linux distribution, all that is required now is to download the binary and execute:

sudo ./rexray service install

What does that do? In short the above command will determine if the Linux distribution uses systemctl, update-rc.d, or chkconfig to manage system services. After that the following steps occur:

1. The path /opt/rexray is created and chowned to root:root with permissions set to 0755.

2. The binary is copied to /opt/rexray/rexray and chowned to root:root with permissions set to 4755. This is important, because this means that any non-privileged user can execute the rexray binary as root without requiring sudo privileges. For more information on this feature, please read about the Linux kernel's super-user ID (SUID) bit.

   Because the REX-ray binary can now be executed with root privileges by non-root users, the binary can be used by non-root users to easily attach and mount external storage.

3. The directory /etc/rexray is created and chowned to root:root.

The next steps depends on the type of Linux distribution. However, it's important to know that the new version of the REX-ray binary now supports managing its own PID (at /var/run/rexray.pid) when run as a service as well as supports the standard SysV control commands such as start, stop, status, and restart.

For SysV Linux distributions that use chkconfig or update-rc.d, a symlink of the REX-ray binary is created in /etc/init.d and then either chkconfig rexray on or update-rc.d rexray defaults is executed.

Modern Linux distributions have moved to SystemD for controlling services. If the systemctl command is detected when installing REX-ray then a unit file is written to /etc/systemd/system/rexray.service with the following contents:

[Unit]
Description=rexray
Before=docker.service

[Service]
EnvironmentFile=/etc/rexray/rexray.env
ExecStart=/opt/rexray/rexray service start
ExecStart=/opt/rexray/rexray service stop
KillMode=process
Restart=always
StartLimitInterval=0

[Install]
WantedBy=docker.service

Additionally, an environment file (and parent directory) is created at /etc/rexray/rexray.env with the contents:

REXRAY_HOME=/opt/rexray

The REX-ray service is not started immediately upon installation. The install command completes by informing the users that they should visit the REX-ray website for information on how to configure REX-ray's storage drivers. The text to the users also explains how to start the REX-ray service once it's configured using the service command particular to the Linux distribution.

Single Service

This release also removes the need for REX-ray to be configured as multiple service instances in order to provide multiple end-points to such consumers such as Docker. REX-ray's backend now supports an internal, modular design which enables it to host multiple module instances of any module, such as the DockerVolumeDriverModule. In fact, one of the default, included modules is...

Admin Module & HTTP JSON API

The AdminModule enables an HTTP JSON API for managing REX-ray's module system as well as provides a UI to view the currently running modules. Simply start the REX-ray server and then visit the URL http://localhost:7979 in your favorite browser to see what's loaded. Or you can access either of the currently supported REST URLs:

http://localhost:7979/r/module/types

and

http://localhost:7979/r/module/instances

Actually, those aren't the only two URLs, but the others are for internal users as of this point. However, the source is open, so... :)

If you want to know what modules are available by using the CLI, after starting the REX-ray service simply type:

[0]akutz@poppy:rexray$ rexray service module types
[
  {
    "id": 2,
    "name": "DockerVolumeDriverModule",
    "addresses": [
      "unix:///run/docker/plugins/rexray.sock",
      "tcp://:7980"
    ]
  },
  {
    "id": 1,
    "name": "AdminModule",
    "addresses": [
      "tcp://:7979"
    ]
  }
]
[0]akutz@poppy:rexray$

To get a list of the running modules you would type:

[0]akutz@poppy:rexray$ rexray service module instance get
[
  {
    "id": 1,
    "typeId": 1,
    "name": "AdminModule",
    "address": "tcp://:7979",
    "description": "The `REX-ray` admin module",
    "started": true
  },
  {
    "id": 2,
    "typeId": 2,
    "name": "DockerVolumeDriverModule",
    "address": "unix:///run/docker/plugins/rexray.sock",
    "description": "The `REX-ray` Docker VolumeDriver module",
    "started": true
  },
  {
    "id": 3,
    "typeId": 2,
    "name": "DockerVolumeDriverModule",
    "address": "tcp://:7980",
    "description": "The `REX-ray` Docker VolumeDriver module",
    "started": true
  }
]
[0]akutz@poppy:rexray$

Hmmm, you know, the REX-ray CLI looks a litle different in the above examples, doesn't it? About that...

Command Line Interface

The CLI has also been enhanced to present a more simplified view up front to users. The commands are now categorized into logical groups:

[0]akutz@pax:~$ rexray
REX-Ray:
  A guest-based storage introspection tool that enables local
  visibility and management from cloud and storage platforms.

Usage: 
  rexray [flags]
  rexray [command]

Available Commands: 
  volume      The volume manager
  snapshot    The snapshot manager
  device      The device manager
  adapter     The adapter manager
  service     The service controller
  version     Print the version
  help        Help about any command

Global Flags:
  -c, --config="/Users/akutz/.rexray/config.yaml": The REX-Ray configuration file
  -?, --help[=false]: Help for rexray
  -h, --host="tcp://:7979": The REX-Ray service address
  -l, --logLevel="info": The log level (panic, fatal, error, warn, info, debug)
  -v, --verbose[=false]: Print verbose help information

Use "rexray [command] --help" for more information about a command.

Travis-CI Support

REX-ray now supports Travis-CI builds either from the primary REX-ray repository or via a fork. All builds should be executed through the Makefile, which is a Travis-CI default. For the Travis-CI settings please be sure to set the environment variable GO15VENDOREXPERIMENT to 1.

added clone from volume