Changes between Version 1 and Version 2 of Dingbot


Ignore:
Timestamp:
09/20/13 21:17:05 (6 years ago)
Author:
Josh Smift
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Dingbot

    v1 v2  
    99= Background =
    1010
    11 Dingbot's purpose is to run on a newly-provisioned node, and do any one-time setup tasks that aren't otherwise done for you automatically. To use it, you'd put something like
    12 
     11Dingbot's purpose is to run on a newly-provisioned node, and do setup tasks that aren't otherwise done for you automatically. To use it, you'd put something like
    1312
    1413{{{
    1514<services>
    16   <install url="CONFIG-URL" install_path="/tmp" />
    17   <install url="DINGBOT-URL" install_path="/tmp" />
    18   <execute shell="/bin/bash" command="sudo /tmp/dingbot/dingbot CONFIG-FILE HOSTNAME"/>
     15  <install url="CONFIG-URL" install_path="/opt" />
     16  <install url="DINGBOT-URL" install_path="/opt" />
     17  <execute shell="/bin/bash" command="sudo /opt/dingbot/dingbot CONFIG-FILE HOSTNAME"/>
    1918</services>
    2019}}}
     
    3332= Operation =
    3433
    35 The script starts by checking for the presence of a /.dingbot-done file (and just prints a message and exits, if one exists), and finishes by creating that file, so it should only ever actually do anything once, even though it runs every time the node boots. If it does do anything, it logs to `dingbot-{output,errors}-$TIMESTAMP.log` files in `/var/log`.
    36 
    3734The simplest way to see what it does is to look at the code, which is commented in astonishingly verbose detail.
    3835
     
    4138= Configuration =
    4239
    43 Dingbot uses a JSON configuration file to specify things that different experimenters might want to do differently, such as set up certain user accounts, or install certain software packages. You can also use it to do different things on different nodes in your experiment: If you always want to do the same things on all your nodes, you can use the same config file in all of your rspecs; or if you want different things on different nodes, you can have as many different config files as you want, just put the appropriate URL into the appropriate `<node>` section in each rspec.
     40Dingbot uses a JSON configuration file to specify things that different experimenters might want to do differently, such as set up certain user accounts, or install certain software packages. You can also use it to do different things on different nodes in your experiment: If you always want to do the same things on all your nodes, you can use the same config file in all of your rspecs; or if you want different things on different nodes, you can have as many different config files as you want, just put the appropriate URL into the appropriate `<node>` section in each rspec. There's also a general pre- and post-execution hook where you can put an arbitrary command (which could run a script full of arbitrary commands).
    4441
    4542Because the `<install url=...>` element expects a .tar.gz file, the config file also needs to be in a tarball.
     
    4946{{{
    5047{
     48 "prehook": "touch -r /etc/issue /.dingbot-pretest",
     49 "posthook": "touch -r /etc/issue /.dingbot-posttest",
    5150 "packages": [ "fping", "iperf", "rsync", "sudo" ],
    5251 "users":
     
    8584Dingbot makes various simplifying assumptions about its environment; see the code for more details. (The word "FIXME" is a good indicator.)
    8685
    87 One significant limitation of Dingbot is that it only runs once, so if it encounters any transient failures (e.g. it can't install software packages because the node temporarily can't reach the package repo, for whatever reason), it doesn't automatically retry or anything. Using a real system configuration management system (like Cfengine, Puppet, Chef, Salt, etc) could make this more robust.
     86One significant limitation of Dingbot is that if it encounters any transient failures (e.g. it can't install software packages because the node temporarily can't reach the package repo, for whatever reason), it doesn't automatically retry or anything. Using a real system configuration management system (like Cfengine, Puppet, Chef, Salt, etc) could make this more robust.
    8887
    8988Other more comprehensive experimenter tools include post-boot scripts as well, and do everything Dingbot does and a whole lot more. It was originally written to make life easier for one casual amateur experimenter, and isn't really intended to be a comprehensive solution for a wide range of people. But if it helps you use GENI, or serves as a starting point for your own ideas, or just amuses and entertains you, all the better.