The interfaces

An ADAGE plugin is a component-like piece of code that implements a principal interface (plugin) and 5 secondary interfaces (creation, specific_to_generic, pre_configure, specific_deployment, and post_configure). The plugin interface contains methods to retrieve instances of the secondary interfaces as well a pointer to a dpl_info instance and a pointer to aa generic instance.

A very simple interface that contains a method void set_specific (docs::xmlfile *) that shall be used by the plugin to store a reference to the document. See Section about factory for more information on this document.

A very important interface with the method convert. Its goal is to fill the generic description of the application.

1. a new generic instance has to be created (generic is by default empty)

   generic = new docs::generic(utils::xml->create_doc_with_xsd("generic_appl_descr", "generic_appl_descr.xsd"));

2. See xml for information on the ADAGE XML API.

1. When a proc_group is added to the XML, it MUST be also added to the generic internal structures through the method

   generic->add_proc_group(pg_id, pg_xml_node)

   or you can use

   node = generic->add_proc_group(pg_id, pg_type, proc_groups_xml_node)

   which will create the XML node, add it to the tree, and return it.

1. When a process is added to the XML, it MUST be also added to the generic internal structures through the method

   generic->add_process(pg_id, proc_id, proc_xml_node)

   or you can use

   node = generic->add_process(proc_id, proc_group_xml_node, parent_proc_group_id)

   . Have a look at TEST plugin for an example of how to use these methods.

1. The generic XML document should be validated thanks to the following call

   utils::xml->validate(generic->get_doc(), "ccm_generic_in_memory")

2. Last, the generic document MUST be added to the docs:

   docs->add_generic(this, generic);

Interface whose method is called after the computation of the deployment plan but before its execution.

This interface provides methods called during the execution of the deployment plan.

1. new_pg(pg_id, pg_card) is called for each proc_group to be executed.
2. bool pg_is_asynchronous() is called internally. It must returns true if the proc_group can be launched in background. If one of the proc_group needs another proc_group to be executed _and_ finished, run the latter synchronously.
3. string get_launcher() is called for each process group to be executed, just after pg_is_asynchronous(). It returns a string containing the path to the specific launcher.
4. new_node(node_id, nb_pg_inst_on_node) is called for each association_node in the current association_pg.
5. bool new_process(proc_id, implem_id, proc_card) is called for each process in the current association_node. If it returns true, new_process_instance(cur_pg_inst_on_node, cur_proc_inst) is called for each instance of the process on the node.
6. string get_pre_args() handles environment and file to wait/file to dump names. Syntax : see deployer/PROTOCOL.
7. string get_exec_and_args() returns a string containing wrk_dir, binaries and arguments. If current proc_group is collective, get_pre_args() and get_exec_and_args() are called only once, just before running the command line. Otherwise, they are called for each instance of process on each node, get_pre_args() before new_process_instance() (if it has to be called, wrt return value of new_process()), and get_exec_and_args() after.

Interface whose method is called after the execution of the plan.

Index, Previous page