In some environments, users may wish to use Wallaby to serve configurations to nodes that can’t reach the Qpid broker that the Wallaby agent is running against. Some users may also want to write simple scripts that access current or historical configuration data without writing a QMF console. The wallaby http-server command, which is available beginning with wallaby-0.9.19, offers a solution for such users. It provides a read-only web service gateway to a node’s configuration: the last activated configuration, a particular version, and the node’s current configuration in the store (which may not yet have been activated).
wallaby http-server requires that the Sinatra framework is installed. If you are building RPMs for wallaby, wallaby-http-server will be built as a separate package, and only if you’re building from Fedora 12 or later. If you’re installing from source, simply gem install sinatra before running the HTTP server; if you’ve already installed a wallaby package on a non-Fedora system, you can simply install cmd_http_server.rb from the source repository into your wallaby shell commands directory. (In the future, we expect to package wallaby-http-server for Red Hat Enterprise Linux as well, thus simplifying this process.)
The transcript below shows the HTTP server’s built-in help, listing all of the methods it supports (as of wallaby-0.9.20, which will be released later today). Please let us know if you can think of other API methods that would be useful to expose over the Wallaby HTTP server.
Online help for the Wallaby HTTP server
[willb@localhost ~/devel/wallaby]% curl http://localhost:4567/help
The Wallaby HTTP server provides read-only access to node
configurations. It understands the following requests:
GET /config/$NODENAME/
returns a configuration file with the last activated
configuration for $NODENAME.
GET /config/$NODENAME/at/$VERSION/
returns a configuration file with the latest configuration
for $NODENAME that is not more recent than $VERSION.
GET /current-config/$NODENAME/
returns a configuration file with the "current"
configuration for $NODENAME, possibly reflecting changes
made since the last activation.
GET /changes-to/$NODENAME/since/$VERSION/
returns a configuration file for the last activated
configuration for $NODENAME, including comments at the
beginning indicating which parameters have changed since
$VERSION and which subsystems are affected by these changes.
GET /help/
returns this message