This tutorial will guide you through FireWorks installation on the central server and one or more worker nodes. The purpose of this tutorial is to get you set up as quickly as possible; it isn’t intended to demonstrate the features of FireWorks or explain things in great detail.
This tutorial can be safely completed from the command line, and requires no programming.
The FireWorks central server (FireServer) hosts the FireWorks database. For production, you should choose a central server that has a fixed IP address/hostname so that you can connect to it from other machines reliably. For initially testing the installation, it should be OK to use a laptop or workstation with a dynamic IP. To set up a FireServer:
Follow the instructions listed at Basic FireWorks Installation.
Install MongoDB on the server.
Start MongoDB:
mongod &
You are now ready to start playing with FireWorks!
Navigate to the FireWorks installation tutorial directory:
cd <INSTALL_DIR>/fw_tutorials/installation
where <INSTALL_DIR> is your FireWorks installation directory.
Initialize the FireWorks database:
launchpad_run.py initialize <TODAY'S DATE>
where <TODAY’S DATE> is formatted like ‘2012-12-31’ (this is a safeguard to prevent accidentally overwriting an existing database).
Note
If you are already curious about the various options that the LaunchPad offers, you can type launchpad_run.py -h.
A FireWork is a workflow. For this tutorial, we will use a FireWork that consists of only a single step. We’ll tackle more complex workflows in other tutorials.
Staying in the tutorial directory, run the following command:
launchpad_run.py upsert_fw fw_test.yaml
Confirm that the FireWork got added to the database:
launchpad_run.py get_fw 1
This prints out the FireWork with fw_id=1 (the first FireWork entered into the database). Notice the part of the FireWork that reads: echo "howdy, your job launched successfully!" >> howdy.txt". When the workflow is run, this is the command that will be executed (print some text into a file named howdy.txt). The use_shell parameter indicates that the command will be interpreted through the shell.
You have now stored a FireWork in the database! It is now ready to be launched.
A Rocket fetches a FireWork (workflow) from the FireServer database and runs it. Usually, a Rocket would be run on a separate machine (FireWorker) and through a queuing system. For now, we will run the Rocket on the FireServer itself and without a queue.
Navigate to any clean directory. For example:
mkdir ~/fw_tests
cd ~/fw_tests
Execute the following command (once):
rocket_run.py
The Rocket fetches an available FireWork from the FireServer and runs it.
Verify that the desired task ran:
cat howdy.txt
You should see the text howdy, your job launched successfully!
Note
In addition to howdy.txt, you should also see a file called fw.json. This contains a JSON representation of the FireWork that the Rocket ran.
Check the status of your FireWork:
launchpad_run.py get_fw 1
You should see additional information indicating that your FireWork was launched.
Try launching another rocket (you should get an error):
rocket_run.py
The error No FireWorks are ready to run and match query! indicates that the Rocket tried to fetch a FireWork from the database, but none could be found. Indeed, we had previously run the only FireWork that was in the database. If you wanted, you could go back, add another FireWork, and run rocket_run.py again in a new directory.
So far, we have added a FireWork (workflow) to the database on the FireServer (central server). We then launched a Rocket that fetched the FireWork from the database and executed it, all within the same machine.
A more interesting use case of FireWorks is to add FireWorks to the FireServer, but execute them on one or several outside ‘worker’ machine (FireWorkers), perhaps through a queueing system. We’ll next configure a worker machine.
On the worker machine, follow the instructions listed at Basic FireWorks Installation.
Back at the FireServer, let’s reset our database add a new FireWork:
launchpad_run.py initialize <TODAY'S DATE>
launchpad_run.py upsert_fw fw_test.yaml
Make sure to keep the FireWorks database running, and do not launch a Rocket yet!
The FireWorker needs to know the login information for the FireServer. On the FireWorker,
Navigate to the installation tutorial directory:
cd <INSTALL_DIR>/fw_tutorials/installation
where <INSTALL_DIR> is your FireWorks installation directory.
Copy the LaunchPad file to a new name:
cp launchpad.yaml my_launchpad.yaml
Modify your my_launchpad.yaml to contain the credentials of your FireServer. In particular, the hostname parameter must be changed to the IP address of your FireServer.
Confirm that you can access the FireServer from your FireWorker:
launchpad_run.py -l my_launchpad.yaml get_fw 1
Note
If you cannot connect to the database from a remote server, you might want to check your Firewall settings and ensure that port 27017 (the default Mongo port) is open/forwarded. For Macs, you might try the Port Map application to easily open ports.
This should print out a FireWork.
Staying in the installation tutorial directory on the FireWorker,
Copy the FireWorker file to a new name:
cp fworker.yaml my_fworker.yaml
Modify your my_fworker.yaml by changing the url parameter to the worker host. This will help you identify the worker that ran your FireWork later on.
Staying in the installation tutorial directory on your FireWorker, type:
rocket_run.py -l my_launchpad.yaml -w my_fworker.yaml
This should successfully launch a rocket that finds and runs your FireWork from the central server.
Confirm that the FireWork was run:
launchpad_run.py -l my_launchpad.yaml get_fw 1
You should notice that the FireWork is listed as being COMPLETED. In addition, the name parameter under the launch_data field should match the name that you gave to your FireWorker in my_fworker.yaml.
If your FireWorker is a large, shared resource (such as a computing cluster or supercomputing center), you probably won’t want to launch Rockets directly. Instead, you’ll submit Rockets through an existing queueing system allocates computer time. The RocketLauncher helps launch Rockets through a queue.
The RocketLauncher needs to know how to communicate with your queue system and the executable to submit to the queue (in our case, a Rocket). These parameters are defined through the RocketParams file.
Note
If you cannot find a working RocketParams file for your specific queuing system, please contact us for help! (see Contributing and Contact) Don’t be shy, we want to help you get set up.
Copy your chosen RocketParams file to a new name:
cp rocketparams_<QUEUE>.yaml my_rocketparams.yaml
Open my_rocketparams.yaml and modify it as follows:
Note
Be sure to indicate the full, absolute path name; do not use BASH shortcuts like ‘.’, ‘..’, or ‘~’, and do not indicate a relative path.
Try submitting a job using the command:
rocket_launcher_run.py singleshot my_rocketparams.yaml
If everything ran successfully, congratulations! You just executed a complicated sequence of instructions:
- The RocketLauncher submitted a Rocket to your queue manager
- Your queue manager executed the Rocket when resources were ready
- The Rocket fetched a FireWork from the FireServer and ran the specification inside
While launching a single job to a queue is nice, a more powerful use case is to submit a large number of jobs at once, or to maintain a certain number of jobs in the queue. The RocketLauncher can be run in a “rapid-fire” mode that provides these features.
Back at the FireServer, let’s reset our database add three new FireWorks:
launchpad_run.py initialize <TODAY'S DATE>
launchpad_run.py upsert_fw fw_test.yaml
launchpad_run.py upsert_fw fw_test.yaml
launchpad_run.py upsert_fw fw_test.yaml
Confirm that you have three FireWorks total:
launchpad_run.py get_fw_ids
You should get back an array containing three FireWork ids.
Switching to your FireWorker,
Navigate to a clean testing directory on the FireWorker:
mkdir ~/rapidfire_tests
cd ~/rapidfire_tests
Copy your RocketParams file to this testing directory:
cp <PATH_TO_MY_ROCKET_PARAMS> .
where <PATH_TO_MY_ROCKET_PARAMS> is the path to my_rocketparams.yaml file that you created in the previous section.
Looking inside my_rocketparams.yaml, confirm that the path to my_fworker.yaml and my_launchpad.yaml are still valid. (They should be, unless you moved or deleted these files)
Submit several jobs with a single command:
rocket_launcher_run.py rapidfire -q 3 my_rocketparams.yaml
Important
The RocketLauncher sleeps between each job submission to give time for the queue manager to ‘breathe’. It might take a few minutes to submit all the jobs.
Important
The command above submits jobs until you have at most 3 jobs in the queue. If you had some jobs existing in the queue before running this command, you might need to increase the -q parameter.
The rapid-fire command should have created a directory beginning with the tag block_. Navigate inside this directory, and confirm that three directories starting with the tag launch were created. The launch directories contain your individual jobs.
You’ve now launched multiple Rockets with a single command!
Note
For more tips on the RocketLauncher, such as how to maintain a certain number of jobs in the queue, read its built-in help: rocketlauncher_run.py rapidfire -h
If you’ve completed this tutorial, your FireServer and a single FireWorker are ready for business! If you’d like, you can now configure more FireWorkers. However, you’re most likely interested in running more complex jobs and creating multi-step workflows. We’ll continue the tutorial with how to better define jobs using FireTasks.