Execution plugin package.

aria.orchestrator.execution_plugin.python_script_scope(*args, **kwds)


Execution plugin utilities.

aria.orchestrator.execution_plugin.common.check_error(ctx, error_check_func=None, reraise=False)
aria.orchestrator.execution_plugin.common.create_process_config(script_path, process, operation_kwargs, quote_json_env_vars=False)

Updates a process with its environment variables, and return it.

Gets a dict representing a process and a dict representing the environment variables. Converts each environment variable to a format of:

<string representing the name of the variable>:
<json formatted string representing the value of the variable>.

Finally, updates the process with the newly formatted environment variables, and return the process.

  • process (dict) – dict representing a process
  • operation_kwargs (dict) – dict representing environment variables that should exist in the process’s running environment.

process updated with its environment variables

Return type:


aria.orchestrator.execution_plugin.common.download_script(ctx, script_path)


Utilities for managing globals for the environment.


Emulates a globals() call in a freshly loaded module.

The implementation of this function is likely to raise a couple of questions. If you read the implementation and nothing bothered you, feel free to skip the rest of this docstring.

First, why is this function in its own module and not, say, in the same module of the other environment-related functions? Second, why is it implemented in such a way that copies the globals, then deletes the item that represents this function, and then changes some other entries?

Well, these two questions can be answered with one (elaborate) explanation. If this function was in the same module with the other environment-related functions, then we would have had to delete more items in globals than just create_initial_globals. That is because all of the other function names would also be in globals, and since there is no built-in mechanism that return the name of the user-defined objects, this approach is quite an overkill.

But why do we rely on the copy-existing-globals-and-delete-entries method, when it seems to force us to put ``create_initial_globals`` in its own file?

Well, because there is no easier method of creating globals of a newly loaded module.

How about hard coding a ``globals`` dict? It seems that there are very few entries: ``__doc__``, ``__file__``, ``__name__``, ``__package__`` (but don’t forget ``__builtins__``).

That would be coupling our implementation to a specific globals implementation. What if globals were to change?


Execution plugin exceptions.

exception aria.orchestrator.execution_plugin.exceptions.ProcessException(stderr=None, stdout=None, command=None, exit_code=None)

Bases: exceptions.Exception

Raised when local scripts and remote SSH commands fail.

exception aria.orchestrator.execution_plugin.exceptions.ScriptException(message=None, retry=None, retry_interval=None)

Bases: exceptions.Exception

Used by the ctx proxy server when task.retry or task.abort are called by scripts.

exception aria.orchestrator.execution_plugin.exceptions.TaskException

Bases: exceptions.Exception

Raised when remote ssh scripts fail.


Instantiation of Operation models.



Local execution of operations.

aria.orchestrator.execution_plugin.local.run_script(ctx, script_path, process, **kwargs)


Entry point functions.