Release Notes - Alfred v2.0

Features added in 2.0  (Nov 1996)

Improved user interface

• compact job-queue window

   

• Separate job tree (DAG) window for each job

   

• Animated percent-done bars on individual task nodes

   

• Simplified per-task menu interface to detailed information

   

• Automatic scrolling to active tasks

   

• Clearer indication of runtime errors, and a scroll-to-error button

   

• A fixed number of automatic retries can be set for tasks with errors

   

• A single menu selection now manually restarts all tasks with errors

   

• The middle mouse-button now retrieves per-task output logs

   

• Improved user interfaces for Crew, Server, and User group definitions

   

• Overall better interactive responsiveness

   

• See the Monitor document for examples and details.

Web browsers as alternative UIs

• Web browsers can connect to alfred to get job status information. This includes a textual version of the task tree, and periodic updates of active jobs.

   

• This feature is built-in to alfred and doesn't require any interaction with (or configuration of) other web servers.

   

• Preview/download of finished frames is supported (for compliant job chaser commands).

   

• Access is controlled by security settings in the alfred.ini file, and with per-user passwords.

New dispatching features

• Crew Priorities can now override the maitre-d queue when several dispatchers are sharing (competing for) remote servers.

   

• Servers can be ranked so that the maitre-d assigns the "best" (highest UDI) servers first.

   

• Remote server definitions have been changed to support a list of arbitrary server type attributes (instead of the previous single service type). This allows alfred scripts to request remote servers using selection keyword search expressions, for example: "nrmserver,(big|fast)".

   

• These server type keys also provide a mechanism for describing a single remote system which can be used as several different, mutually exclusive, types of servers. For example, a service definition which includes the selection keys "nrmserver maya" might indicate that the given host can support two types of rendering software. If a command requiring an nrmserver checks this server out from the maitre-d it will be unavailable for any other type of work while that command is running; but when it is available the next command that gets it might use it Maya rendering. This mutual exclusion of service types on a single server is a new feature which complements the existing parallel-slot feature; several distinct alfred Service definitions can be defined which reference the same physical host. In this case several commands executing in parallel may be communicating with different servers on the same host (e.g. multiple nrmserver slots on a multi-processor system).

   

• The maitre-d now keeps a tally of special command tags which can be used to limit certain types of activity. One common use is to restrict the number of simultaneous launches of an application which has a fixed number of licenses available. Another use is to limit the number of concurrently executing client apps which are tagged as too CPU "intensive" to be running together.

   

• The built-in server status checking mechanism (server-ping) is much faster (and the old nrmping executable is no longer needed). Sites can also define custom server query commands in the alfred.schedule file; these are run by the maitre-d, based on server type, to determine if a remote server is really available.

   

• A group (sub-DAG) of task nodes can now share the same remote host which is checked out once by the top level task.

   

• Clean-up commands of active tasks are now run "aggressively" during job delete, to remove temporary files for example.

NIMBY

• The not-in-my-back-yard desktop utility disables the current host as an alfred server when it's in use interactively

   

• Allows jobs from remote dispatchers when the user has been idle (i.e. when the screen-saver is active)

   

• See the NIMBY document for examples and details.

Miscellaneous features

 

• Alfred's balloon-help text is now in the plain-text file $RMANTREE/lib/alfred/resources/alfred.help where it can be site-customized more easily.

   

• The output logs for all tasks are now in a single file in the spool directory (one per active job). This makes clean-ups easier and the whole spool directory more tidy. If tasks produce a lot of output (megabytes) the "See Output Logs" operation can take a while to scan through the logfile looking for lines corresponding to a particular task.

   

• There are many new language features; and a backward-compatible operator syntax which uses "-option value" pairs. Also the old "Expand" operator is obsolete and its function has been subsumed by the new "-expand" option to the Cmd operator.

   

• Only one predefined/reserved TCP port is required now (for the maitre-d; dispatcher ports are now generated at runtime). See the alfred.ini file for details. This new scheme adds one new requirement for people who use remote UIs (the "alfred -h host" mode); an rsh is used to simultaneously confirm remote-login permission and to retrieve the dispatcher port, hence these users must have a .cshrc which behaves when invoked under rsh. The command "rsh remotehost ls" should be a sufficient test of a working configuration.

   

• The provided script ralf is a wrapper around "rsh" which can (usually) collect the exit status of the remote command (whereas straight rsh returns it's own success/failure code). This can be useful in alfred scripts which need to launch apps on remote servers (as opposed to scripts which launch client apps that contact remote servers, ralf/rsh is the client in this case).

   

• Many initial-startup checks are now done before the daemon's put themselves in the background.

   

• There are now more thorough schedule consistency checks on start-up.

   

• The environment variables LD_LIBRARY_PATH and AW_LOCATION are set by alfred in case it launches ATOR to process an Alias wirefile.

   

• The maitre-d will reread the schedule and limit values when it receives a SIGHUP signal.

   

• The dispatcher will checkpoint all jobs, terminate running tasks, and exit when it receives a SIGTERM signal. Note that TERM, 15, is the default signal for kill(1), but killall(1) defaults to KILL, 9.

   

• Alfred preferences are now saved in the the ~/.pixarPrefs directory instead of the now-obsolete ~/.alfredPrefs file.

   

• There is a new -unpause option which resumes dispatching if the dispatcher is currently paused.