-
Notifications
You must be signed in to change notification settings - Fork 3
Contents
Of course, googling sequencer does not lead to this project. However googling sequencer bull directly links to the github sequencer page. Therefore, remember that the sequencer project is supported by the Bull company.
If you have any good knowledge in those technologies, please feel free to correct us.
As far as we know, none of those products support dependencies between components.
From the Capistrano getting started link,
defining a new task is quite similar to the sequencer way. A file
should be written with informations about what the task is supposed to
do, and on which host it should be applied to. Compare the "Simple
Example" with sequencer's equivalent (using host phobos instead of
www.capify.org):
$ sequencer dbadd search_libs cmd ALL '%id =~ phobos' '@ls -x1 /usr/lib | grep -i xml' NONE NONE "Capistrano Simple Example Equivalent"
$ sequencer dbshow search_libs
ruleset | name | types | filter | action | depsfinder | dependson | comments |
----------------------------------------------------------------------------------------------------------------------------------------------
search_libs | cmd | ALL | %id =~ phobos | @ls -x1 /usr/lib | grep -i xml | NONE | NONE | Capistrano Simple Example Equivalent |
$ sequencer search_libs localhost phobos
phobos#exotic@alien/cmd: [node=phobos] libakonadi-xml.so
phobos#exotic@alien/cmd: [node=phobos] libakonadi-xml.so.4
phobos#exotic@alien/cmd: [node=phobos] libakonadi-xml.so.4.6.0
phobos#exotic@alien/cmd: [node=phobos] libixml.a
phobos#exotic@alien/cmd: [node=phobos] libixml.la
phobos#exotic@alien/cmd: [node=phobos] libixml.so
phobos#exotic@alien/cmd: [node=phobos] libixml.so.2
phobos#exotic@alien/cmd: [node=phobos] libixml.so.2.0.4
phobos#exotic@alien/cmd: [node=phobos] libkxmlrpcclient.so
phobos#exotic@alien/cmd: [node=phobos] libkxmlrpcclient.so.4
phobos#exotic@alien/cmd: [node=phobos] libkxmlrpcclient.so.4.6.0
phobos#exotic@alien/cmd: [node=phobos] libwx_baseu_xml-2.8.so
phobos#exotic@alien/cmd: [node=phobos] libwx_baseu_xml-2.8.so.0
phobos#exotic@alien/cmd: [node=phobos] libwx_baseu_xml-2.8.so.0.7.0
phobos#exotic@alien/cmd: [node=phobos] libxml2.a
phobos#exotic@alien/cmd: [node=phobos] libxml2.la
phobos#exotic@alien/cmd: [node=phobos] libxml2.so
phobos#exotic@alien/cmd: [node=phobos] libxml2.so.2
phobos#exotic@alien/cmd: [node=phobos] libxml2.so.2.7.8
phobos#exotic@alien/cmd: [node=phobos] xml2Conf.sh
$
As shown, nothing was executed on localhost thanks to the filter.
From the Fabric tutorial, Fabric requires python programming. This is not the case with the sequencer which is mainly based on scripts and therefore is language neutral. Note however than since the sequencer is written in python, its API can be used by a python program.
On the other side, Fabric allows tasks (equivalent to sequencer actions) to have parameters. This is currently not supported by the sequencer but is planned for a next future.
Smart handling of failures is also provided in both products but in very different ways.
Puppets focuses on configuration, the sequencer focuses on actions. There is no "state" concept in the sequencer. Puppet applies a configuration to a given set of components. This usually leads to the execution of various command on several nodes for ensuring that their configuration matches a pre-defined one. Basically, puppet slaves will retrieve from the puppet master their configuration and launch the related command. A kind of 'pull' mode.
The sequencer is rather different and it compares better to a dispatch framework such as Func or Controltier. Actions are more "pushed" to components than "pulled" from them, but they are often local to the master node (using ipmitool as the backend for example). By the way, the order in which those actions are executed is deterministic which is not the case in Puppet (but it is in Chef).
From a technical point of view, puppet and chef relies on a client-server paradigm: in particular a daemon is running on each node, and on the master. There is no such things with the sequencer which is a script. Actions launched by the sequencer may require the client/server paradigm (IPMI, SSH), but this is not a requirement of the sequencer engine itself. By the way, since they use slave daemons on nodes, it seems difficult at first glance to use Puppet or Chef for powering on/off components. When the given node is powered off, the puppet master has no way to check the configuration status of the given node (it cannot contact the slave).
The sequencer home page: http://vigneras.github.com/sequencer/
Contact & Support: http://vigneras.github.com/sequencer/index.html#contact