Overview

Users must authenticate to the AMQP broker before using Wallaby (although some installations may allow users to authenticate as “anonymous”), but previous versions of Wallaby implicitly authorized any user who had authenticated to the broker to perform any action. Wallaby now includes a database mapping from user names to roles, which allows installations to define how each broker user can interact with Wallaby. Each method is annotated with the role required to invoke it, and each method invocation is checked to ensure that the currently-authenticated user is authorized to assume the role required by the method. The roles Wallaby recognizes are NONE, READ, WRITE, or ADMIN, where each role includes all of the capabilities of the role that preceded it.

If WALLABY_USERDB_NAME is set in the Wallaby agent’s environment upon startup and represents a valid pathname, Wallaby will use that as the location of the user-role database. If this variable is set to a valid pathname but no file exists at that pathname, the Wallaby user-role database will be created upon agent startup. If WALLABY_USERDB_NAME is not set, the user-role database will be initialized in memory only and thus will not persist across agent restarts.

Standard authorization

When Wallaby is about to service an API request, it:

1. checks the role required to invoke the method.

2. checks the authorization level specified for the user. There are several possibilities under which a user could be authorized to invoke a method:

   • the user is explicitly authorized for a role that includes the required role (e.g. the user has an ADMIN role but the method only requires READ);
   • the user is implicitly authorized for a role that includes the required role (e.g. there is an entry for the wildcard user * giving it READ access and the method requires READ access)
   • the role database is empty, in which case all authenticated users are implicitly authorized for all actions (this is the same behavior as in older versions of Wallaby)
   • the invocation is of a user-role database maintenance method and the client is authorized via shared secret (see below)

3. if none of the conditions of the above step hold, the method invocation is unauthorized and fails with an API-level error. If the API method is invoked over the Ruby client library, it will raise an exception. If it is invoked via a wallaby shell command-line tool, it will print a human-readable error message and exit with a nonzero exit status.

4. if the user is authorized to invoke the method, invocation proceeds normally.

Authorization with secret-based authentication

This version of the Wallaby API introduces three new methods: Store#set_user_privs, Store#del_user, and Store#users. These enable updating and reading the user-role database; the first two require ADMIN access, while the last requires READ access. Because changes in the user-role database may result in an administrator inadvertently removing administrator rights from his or her broker user, Wallaby provides another mechanism to authorize access to these methods. Each of these three methods supports a special secret option in its options argument. When the Wallaby service starts up, it loads a secret string from a file. Clients that supply the correct secret as an option to one of these calls will be authorized to invoke these calls, even if the broker user making the invocation is not authorized by the user-role database.

The pathname to the secret file is given by the environment variable WALLABY_SECRET_FILE. If this variable is unset upon agent startup, Wallaby will not use a shared secret (and secret-based authorization will not be available to API clients). It this variable is set and names an existing file that the Wallaby agent user can read, the Wallaby shared secret will be set to the entire contents of this file. If this variable is set and names a nonexistent file in a path that does exist, Wallaby will create a file at this path upon startup with a randomly-generated secret (consisting of a digest hash of some data read from /dev/urandom). If this variable is set to a pathname that includes nonexistent directory components, the Wallaby agent will raise an error. If you create your own secret file, ensure that it is only readable by the UNIX user that the Wallaby agent runs as (typically wallaby).

Caveats

The Wallaby agent’s authorization support is designed to prevent broker users from altering Condor pool configurations in excess of their authority. It is not intended to keep all configuration data strictly confidential. (This is not as bad as it might sound, since Wallaby-generated configurations are available for inspection by Condor users.) Furthermore, due to technical limitations, it is not possible to protect object property accesses over the API with the same authorization support that we use for API method invocations. Therefore, if concealing configuration data from some subset of users is important for your installation, you should prevent these users from authenticating to the broker that the Wallaby agent runs on.

Getting started

Here is a quick overview of how to get started with auth-enabled Wallaby:

1. Stop your running Wallaby and restart your broker before starting the new Wallaby (this is necessary to pick up the new API methods). Set WALLABY_USERDB_NAME in your environment to a path where you can store the user-role database. Install and start your new Wallaby.
2. If you’re using the RPM package, it will create a “secret file” for you in /var/lib/wallaby/secret. If not, you will need to set WALLABY_SECRET_FILE in the environment to specify a location for this secret file and then restart Wallaby. The Wallaby secret is a special token that can be passed to certain API methods (specifically, those related to user database management) in order to authorize users who aren’t authorized in the user database.
3. Try using some of the new shell commands: wallaby set-user-role, wallaby list-users, and wallaby delete-user.
4. Make sure that you have a secret in your secret file. Make a note of it. Try setting the role for your current broker user to READ or NONE (e.g. “wallaby set-user-role anonymous NONE”) and then see what happens when you try and run some other Wallaby shell commands. You can recover from this by passing the Wallaby secret to “wallaby set-user-role”; see its online help for details.

The default user database is empty, which will result in the same behavior as in older versions of Wallaby (viz., all actions are available to all broker users), but only until a user role is added, at which point all actions must be explicitly or implicitly authorized.

This article is cross-posted from Chapeau

Some of the technologies that the current version of Wallaby is built upon do not lend themselves to traditional active-active high-availability solutions. However, the good news is that due to Wallaby’s architecture, almost all running Condor nodes will not be affected by a failure of the Wallaby service or the machine it is running on. Nodes that have already checked in with Wallaby will have their latest activated configurations as of the last checking. The only limitations in the event of service failure are:

1. new nodes will not be able to check in and get the default configuration;
2. it will not be possible to access older activated configurations; and
3. it will not be possible to alter, activate, or deploy the configuration.

These limitations, of course, disappear when the service is restored. For most users, losing the ability to update or deploy configurations due to a service failure — but not losing their deployed configurations or otherwise affecting normal pool operation — represents an acceptable risk. Some installations, especially those who aggressively exploit Wallaby’s scripting interface or versioning capability, may want a more robust solution: these users might want to be able to access older versions of their activated configurations even if Wallaby is down, or they might want a mechanism to speed recovery by starting a replica of their service on another machine. In the remainder of this post, we’ll discuss some approaches to provide more access to Wallaby data when Wallaby is down.

Accessing older versioned configurations

If you need to access historical versioned configurations, the easiest way to do it is to set up a cron job on the machine running Wallaby that periodically runs wallaby vc-export on your snapshot database and outputs versioned configurations to a shared filesystem. wallaby vc-export, which is documented in this post, exports all historical snapshots to plain-text files, so you can access the configuration for foo.example.com at version 1234 in a file called something like 1234/nodes/foo.example.com. This cron job needs to be able to access the filesystem path of the Wallaby snapshot database; furthermore, to run it efficiently, you’ll probably want to limit the number of snapshots it processes each time; see wallaby vc-export’s online help for more details.

Exporting Wallaby state to a file

If you’re just interested in the state of the Wallaby service (including possibly unactivated changes), you can periodically run wallaby dump over the network. This will produce a YAML file consisting of the serialized state of the Wallaby; you can later load this file by using the wallaby load command, possibly against another Wallaby agent.

Backing up the raw database files

The easiest way to pick up and recover from a Wallaby node failure is to start a new Wallaby service with the same databases as the failed node. In turn, the easiest way to do this is by periodically copying these database files from their locations on the Wallaby node (typically in /var/lib/wallaby) to some location on a shared filesystem. The following Ruby script will safely copy the SQLite files that Wallaby uses even while Wallaby is running:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#!/usr/lib/env ruby

# Acquires a shared lock on a SQLite database file and copies it to a backup
# usage:  backup-db.rb DBFILE.db BACKUPFILE.db
# author:  William Benton (willb@redhat.com)
# Public domain.

require 'sqlite3'
require 'fileutils'

def backup_db(db_file, backup_file)
  begin
    db = SQLite3::Database.new(db_file)

    db.transaction(:immediate) do |ignored|
      # starting a transaction with ":immediate" means we get a shared lock
      # and thus any db writes (unlikely!) complete before we copy the file
      FileUtils.cp(db_file, backup_file, :preserve=>true)
    end
  ensure
    db.close
  end
end

backup_db(ARGV[0], ARGV[1])

(cross-posted from Chapeau)

The default group provides a convenient mechanism to apply some configuration to every node in a pool, whether or not it has been explicitly configured; this enables us to provide some sensible basic configuration for nodes that are added to the pool opportunistically or from the cloud. However, for some applications, using the default group may be inflexible because of Wallaby’s additive, compositional configuration model. For example, what if you want to enable some functionality by default but disable it on some subset of nodes? Or what if you want to use “defaults” to override some settings made in explicit groups?

The skeleton group provides a solution to these problems. (The “skeleton group” is so named by analogy with the /etc/skel directory on Linux systems, which provides a template for the home directories of newly-created users.) Like the default group, every new node is added to the skeleton group when it is created and receives the last-activated configuration for the skeleton group. Unlike the default group, individual nodes’ skeleton group memberships can be at different priorities; furthermore, nodes can be removed from the skeleton group all together. In this post, we’ll see how to set it up and use it.

1. Ensure that you’re running Wallaby 0.15.0 or later. (Some older versions also include experimental support for the skeleton group, but Wallaby 0.15.0 eliminates many rough edges and is the recommended minimum version for using the skeleton group.)
2. Change the environment that your wallaby-agent runs in so that WALLABY_ENABLE_SKELETON_GROUP is set to true. The easiest way to do this is to modify the /etc/sysconfig/wallaby-agent file (on RHEL 5 and 6) or the /etc/sysconfig/wallaby-agent-env file (on Fedora).
3. Restart Wallaby by running service wallaby restart (on RHEL 5 and 6) or systemctl restart wallaby.service (on Fedora).
4. Create a new node, either explicitly (e.g. wallaby add-node foo.local.) or by having a new node check in; note that its memberships include +++SKEL. This is the skeleton group. (Preexisting nodes won’t be in the skeleton group by default, but it’s straightforward to add them all via the Wallaby shell.)

Now that you have it set up, here are some things to try doing with it:

1. Put some of your default-group configuration in the skeleton group. Note that the skeleton group will be validated in isolation just as the default group is, but the validation procedure for the skeleton group assumes that the default group configuration has also been applied already — so your skeleton group configuration will need to be valid when applied atop the default group configuration. (This is so that newly-created nodes will have a valid configuration.)
2. Put configuration that you want to override on some nodes in the skeleton group. Then remove these nodes from the skeleton group.
3. Experiment with configurations that depend on the priority of the skeleton group; move it around in nodes’ membership lists.
4. Write a Wallaby shell command to copy the configuration from the skeleton group over to a node’s identity group and then remove that node from the skeleton group (in order to allow further customization).

Let us know how you wind up using this functionality!

If everyone involved uses Wallaby for configuration management, things can be a lot simpler: the site experiencing the problem can use wallaby dump to save the state of their configuration for an entire pool to a flat file, which the troubleshooting site can then inspect or restore with wallaby load. If the problem appears in some configuration snapshots but not in others, the reporting site can use wallaby vc-export to generate a directory of all of their configurations over time, so that the troubleshooting site can attempt to pinpoint the differences between what worked and what didn’t.

(Thanks to Matt for pointing out the value of versioned semantic configuration management in reproducing problems!)

The Wallaby git repository now contains a command to export versioned configurations from a database to flat text files. Clone the repository or just download the file and then place cmd_versioned_config_export.rb somewhere in your WALLABY_SHELL_COMMAND_PATH, and you’ll be able to invoke it like this:

Usage:  wallaby vc-export DBFILE
exports versioned configurations from DBFILE to plain text files
    -h, --help                       displays this message
        --verbose                    outputs information about command progress
    -o, --output-dir DIR             set output directory to DIR
        --earliest NUM               output only the earliest NUM configurations
        --latest NUM                 output only the most recent NUM configurations
        --since DATE                 output only configurations since the given date

It will create a directory (called snapshots by default) with subdirectories for each versioned configuration; each of these will be timestamped with the time of the configuration. Within each version directory, there will be directories for node configurations and stored group configurations. (If you’re using an older version of Wallaby, the only stored group configuration will be for the default group. Versioned configurations generated with a fairly recent version of Wallaby, on the other hand, will have stored configurations for more groups and should also have useful information about node memberships in the configuration file.)

wallaby vc-export allows you both to back up versioned configurations and simply to inspect them. Let us know if you find a new application for it, or if you find it useful in other ways!

(Cross-posted from Chapeau.)

The Wallaby source repository now includes a small Python module that patches the Wallaby python client library with idiomatic tagging support: namely, you can ask the store for the name of the group that represents the partition between tags and groups, and you can call getTags() and modifyTags() methods on Node objects, as well as inspect the tags property of a Node. This will appear in Wallaby packages in the future, but you don’t have to be that adventurous to try it out now! To use it, clone the repository and put extensions/tagging.py and schema/wallaby.py somewhere in your PYTHONPATH. Then follow along with this transcript:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

import wallaby

# the "tagging" module patches the Wallaby client library with 
# support for tag operations
import tagging

# We'll start by setting up a Wallaby client library session against
# the broker on localhost
from qmf.console import Session
console = Session()
console.addBroker()
raw_store, = console.getObjects(_class="Store")
store = wallaby.Store(raw_store, console)

# call this method after the store client is initialized so that
# the tagging library knows how to create missing groups
tagging.setup(store)

# Clear out all of the memberships on a fake node
store.getNode("fake-node.example.com").modifyMemberships("REPLACE", [], {})

# After clearing a node's membership list, it will have no tags
store.getNode("fake-node.example.com").getTags()

# You can also access the tags of a given node via its "tags" attribute
store.getNode("fake-node.example.com").tags

# by convention, we're preceding tags with "@" here
store.getNode("fake-node.example.com").modifyTags("ADD", ["@Foo", "@Blitz"], create_missing_tags=True)

# This should return ["@Foo", "@Blitz"]
store.getNode("fake-node.example.com").tags

# This should return ["===TAGS_BELOW===", "@Foo", "@Blitz"]
store.getNode("fake-node.example.com").memberships

I appreciate any feedback or comments on this library.

(Cross-posted from Chapeau.)

The Wallaby API is designed to be sufficiently general to allow developers to do just about anything with configuration data, not to unnecessarily restrict users to a few use cases that we thought of. Because of this generality, some tasks might require adopting application-level conventions. In this article, we’ll cover one such convention and see how the Wallaby API is flexible enough to handle an interesting use case – namely, tagging nodes with various keywords, perhaps as supplied by a user or generated by an agent like sesame or matahari.

First, though, we’ll review how configurations are generated and applied to nodes. Recall that a node is a member of several groups. These memberships are ordered: a node’s lowest-priority membership is always in the special default group (which includes every node), and its highest-priority membership is always in a special, node-specific identity group (which only includes a single node). Zero or more memberships in explicit groups may occupy the priority space between the default group and a node’s identity group. In the illustration below, node.local is a member of two explicit groups, which have blue backgrounds: “EC2 submit nodes,” and “Execute nodes.”

When Wallaby calculates the configuration for node.local., it will begin with a copy of the default group’s configuration. It will then repeatedly apply the configurations for the explicit groups and identity group in order of increasing priority, so that parameter-value mappings from higher-priority groups take precedence over lower-priority ones (and thus either replace these or are appended to them, depending on the mapping kind). The condor_configd, which takes a node’s configuration from Wallaby and installs it on a node, will also cause the Wallaby groups a node is a member of (as well as the Wallaby features it has installed) to be advertised for use in Condor matchmaking. So a Condor job could specify that it wanted to match against a node that was a member of the “EC2 submit nodes” group; this would translate into a preference for node.local.

Because group names appear in machine ClassAd attributes, the list of explicit node memberships is a natural place to put tag information. Nodes would simply be members of “dummy” groups like “Desktop workstations” or “Machines with more than 8GB RAM,” and these keywords could be used in matchmaking or in searching for particular nodes. However, the list of explicit groups is not necessarily suitable for automatic manipulation: users will not necessarily expect their changes to be overridden, other API clients won’t necessarily expect users to rearrange or remove groups corresponding to tags, and in general it is impossible to determine whether a group membership should be interpreted as a tag or as an explicit membership.

We can adopt a convention to partition the space of group memberships. Say we create a special sentinel group to partition the membership space: every node will be a member of the sentinel group. All memberships that are of a lower priority than the sentinel group will be managed by tagging agents, and all memberships that are of a higher priority will be explicitly managed by the user. In the example below, “–EXPLICIT GROUPS” is the sentinel group, and groups in yellow correspond to tags.

This approach demonstrates the generality of the Wallaby API, and allows users to supply tag-specific configurations by installing parameters or features on tag groups, for example, ensuring that every desktop workstation has a policy that favors its owner, or overprovisioning high-memory nodes. However, it is not free of shortcomings. Firstly, Wallaby will present all of these groups – sentinel, tag, and explicit groups – so a user-facing tool that puts a friendly interface on node memberships and tagging will need to use the sentinel group to partition which groups it displays to the user. Secondly, the sentinel groups must be added to all nodes (in practice, we can assume that the absence of a sentinel group implies the absence of tags); in general, we are relying on clients to enforce invariants in this case. Finally, altering a node’s membership list to insert a tag will cause that node’s configuration to be validated at the next activation. If the node has a complex configuration, this could be expensive.

(Cross-posted from Chapeau.)

(Cross-posted from Chapeau.)

The wallaby source repository now includes a Python client library to interact with a wallaby service. This library does a few things to make your life easier:

1. Raw QMF object proxies are wrapped in Python client objects.
2. Object references returned by QMF methods are automatically wrapped by client objects.
3. QMF methods that return error statuses will raise exceptions in the client library.
4. Client classes include docstrings for QMF methods.

See below for a transcript illustrating these features. Note that you’ll need to have the following packages installed to use the Python wallaby client library: Red Hat Enterprise MRG 1.3 (or the python-qmf package from a recent Fedora release) and Wallaby 0.9.18 or later (0.10.0 to access all of the features exposed through the client library).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

from qmf.console import Session
import wallaby

# create a new console object
console = Session()

# connect to the broker (on localhost:5672, by default)
console.addBroker()
# => Broker connected at: localhost:5672

# find the QMF object for the wallaby service
raw_store, = console.getObjects(_class="Store")

# wrap it up in a client object
store = wallaby.Store(raw_store, console)

# now, interact with it!
node = store.addNode("barney.local.")
feature = store.addFeature("Example feature")
param = store.addParam("EXAMPLE_PARAM")

# most "options" arguments are indeed optional
feature.modifyParams("ADD", {"EXAMPLE_PARAM":"example value"})
store.getDefaultGroup().modifyFeatures("ADD", ["Example feature"])

node.getConfig()
# => {u'WALLABY_CONFIG_VERSION': u'0', u'EXAMPLE_PARAM': u'example value'}

# What does the activateConfiguration method return?
help(store.activateConfiguration)

# Help on method activateConfiguration in module wallaby:
# 
# activateConfiguration(self) method of wallaby.Store instance
#     Returns a tuple consisting of:
#     * A map containing an explanation of why the configuration isn't valid, or an empty map if the configuration was successfully activated.
#     * A set of warnings encountered during configuration activation.

store.activateConfiguration()
# => ({}, [])

node.getConfig()
# => {u'WALLABY_CONFIG_VERSION': u'1292513031757418', u'EXAMPLE_PARAM': u'example value'}

# try something that will cause an error

feature = store.addFeature("Example feature")

# Traceback (most recent call last):
#   File "<stdin>", line 2, in <module>
#   File "wallaby.py", line 404, in addFeature
#     raise ClientError(result.status, result.text)
# wallaby.ClientError: (67109121, u'Feature name Example feature is already taken')

(Cross-posted from Chapeau.)

First, make sure you’re running wallaby 0.9.23 or later. If you’re running Fedora, you can simply git clone the repository, check out the v0.9.23 tag, and run rake rpms to generate installable packages.

Next, you’ll want to have a directory in which to put your custom wallaby shell commands. I recommend putting them somewhere in your home directory. (For the purposes of this discussion, we’ll assume that you’re using ~/.wallaby.) The wallaby command will find and attempt to load every ruby file in this directory that begins with cmd_, so you probably don’t want it to be writable by anyone other than you. Once you have this directory set up, set WALLABY_COMMAND_DIR in your environment to this directory:

export WALLABY_COMMAND_DIR=${HOME}/.wallaby

We’ll start by making a fairly straightforward command that simply prints out the API version supported by the wallaby service. To create a new wallaby command, use wallaby new-command:

The -d option allows us to provide a description for the new command (viz., what would show up if we typed wallaby help commands). The -D option allows us to specify a directory in which to create the new command file. (wallaby new-command supports several other options; you can use wallaby help new-command for additional documentation.) After executing this command, we’ll have a documented template file for a new wallaby command, called cmd_api_version.rb, installed in our WALLABY_COMMAND_DIR. It will look something like this:

We can now run wallaby help commands and verify that our command shows up. Sure enough, it does:

We can even run wallaby api-version, although it won’t do anything yet. To make it do something useful, we’re going to edit the act method defined for us in the ApiVersion class. We could do something very simple, like insert puts store.apiVersionNumber before return 0, but it would be nice to allow a user to format the API version number as he or she sees fit, in order to use the result of our command in other scripts.

To let the user supply a format string, we’ll need to add a command-line option, which requires us to edit the init_option_parser method. This method must return an OptionParser object; if you haven’t used Ruby’s option parser class, read up on its documentation. For this example, though, the changes we have to make are pretty minor.

After we’ve added a command-line option and a body for the act method, our cmd_api_version.rb file will look more like this:

Running this command without arguments will return a string like The wallaby service is running version 20100915 of the Wallaby API. If you supply a format string, you can get simply the raw number (with --format '%s') or something more suited to your taste. (Note that this example script doesn’t do any sanity- or error-checking of the format string, which you’d certainly want to do if you were going to put your command into production.)

We’ll look at a more interesting example wallaby shell command and some of the issues that more interesting commands raise in a future post.

(Cross-posted from Chapeau.)

Recently, I added constraint support to wallaby inventory. That is, instead of listing all nodes, you can choose to list only nodes for which a given Ruby expression is true. These constraints can be simple, like last_checkin < 1.hour_ago (which will find all nodes that have checked in more than one hour ago), or more complex. They are only limited by Ruby’s $SAFE execution: among other things, they cannot modify running classes, perform file I/O, fork new processes, or, because of how QMF is implemented, invoke QMF methods on the node object. However, every QMF property of the node object is available to wallaby inventory constraints. The transcript below provides some examples running against a wallaby agent loaded up with test data.

(Cross-posted from Chapeau.)

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.

(Cross-posted from chapeau.)

If you’re writing a Wallaby API client in Ruby, you can use a couple of nice features to ease development: the Wallaby client library, which presents a more polished interface than dealing with raw QMF queries and calls, and the wallaby console utility, which connects to a specified broker and gives you a Ruby REPL that has a global variable pointing to a store client — perfect for casual, interactive experimentation.

Use the same global command line options for wallaby console as you’d use for any other wallaby subcommand: specifying host, port, and authentication information for the broker. Once you’ve started it up, you’ll be dropped into a Ruby prompt where Wallaby::store is a reference to a client proxy object for your Wallaby store. You can then inspect or modify any entity that the store knows about; the store object has accessors called nodes, features, parameters, etc., that return arrays of each kind of object. Then you can invoke methods on each object. The transcript below shows a session in which the user inspects some details of a node in a trivial pool:

>> Wallaby::store.nodes.map {|n| n.name}
=> ["frotz"]
>> frotz = Wallaby::store.nodes[0] ; nil
=> nil
>> Wallaby::store.groups.map {|g| g.name}
=> ["+++DEFAULT", "+++af413ebf1de0f9d4253eb89717a4e13b"]
>> Wallaby::store.groups[1].features
=> ["DisablePreemption"]
>> frotz.getConfig
=> {"PREEMPT"=>"FALSE", "WALLABY_CONFIG_VERSION"=>"1284180448517726"}

In the future, it will be easier to extend the wallaby command with your own subcommands. For now, however, wallaby console provides a great way to interact with the Wallaby API.

(Cross-posted from Chapeau.)

The basic syntax of the file you’ll pass to wallaby feature-import is the same as the basic syntax of a Condor configuration file; in fact, you can import many Condor configuration files without modification. (Only the NAME = VALUE syntax is supported at this time; you can’t use the NAME = +VALUE syntax for DC_DAEMON_LIST.) However, there are some special directives that you can pass to the configuration file as comments:

#name NAME

Indicates that this feature should be named NAME. (Note that you must supply a name for the feature, either on the command line, via -n NAME, or in the file itself.)

#includes FEATURE

Indicates that this feature should include FEATURE, which must exist in Wallaby.

#dependson FEATURE

Indicates that this feature should depend upon FEATURE, which must exist in Wallaby.

#default PARAM

Indicates that this feature should include PARAM, and set it to its default value.

Because Condor ignores these comments, it is possible to use the same file both as a Condor configuration file and as a Wallaby feature description. (Other comments will be ignored by wallaby feature-import, but they may generate harmless warnings.) wallaby feature-import will automatically create any parameters referenced in the file that don’t already exist in Wallaby’s database; this can be a great time-saver for migrating to Wallaby from a custom configuration-management system.

The following example file is a feature that defines eight startds on a single node:

(Cross-posted from Chapeau.)