Jump to: navigation, search

Difference between revisions of "Mistral/Blueprints/ActionsDesign"

(Mistral Actions)
Line 1: Line 1:
 
=== Mistral Actions ===
 
=== Mistral Actions ===
 +
NOT FINISHED
 +
This BP describes the main requirements to how actions should be designed in Mistral in order to address flexibility and clarity of their usage.
 +
 +
From implementation perspective we'll be referring to python class Action that represents Mistral action:
 +
class Action(object):
 +
    @abc.abstractmethod
 +
    def run():
 +
        pass
 +
 +
Method run() here implements action logic (issuing SSH command, sending a message over MQ etc.). All specific action classes must extend class Action and implement abstract method run().
 +
 +
==== Synchronous/Asynchronous ====
 +
Mistral action can be synchronous and asynchronous. Synchronous actions act as a regular Python method: when it's called it returns a result upon completion so a caller can immediately use this result. Asynchronous actions don't return a result immediately but rather "launch" an independent activity (e.g. sending a request to an external system to do the heavy job) and when it completes a result becomes know to Mistral.
 +
 +
class Action(object):
 +
    @abc.abstractmethod
 +
    def run():
 +
        pass
  
This BP describes the main requirements to how actions should be designed in Mistral in order to address flexibility and clarity of their usage.
+
    def is_sync():
 +
        return False
 +
 
 +
==== Result ====
 +
 
 +
==== Errors ====
  
The questions to answer are:
+
==== Revert ====
* How do we distinguish synchronous and asynchronous actions? What's the formal criteria?
 
* How does action obtain its result?
 
* In what form does action return a result?
 
* Does action need to have revert() method along with run() method?
 
* Does action need to have dry_run() method?
 
* How does action expose errors occurring during it's work?
 
* How would a complete Action interface look like?
 
* How do we treat action input parameters?
 
  
 +
==== Dry-Run ====
  
 +
==== Input ====
  
NOT FINISHED
+
==== Namespaces ====

Revision as of 08:27, 11 March 2014

Mistral Actions

NOT FINISHED

This BP describes the main requirements to how actions should be designed in Mistral in order to address flexibility and clarity of their usage.

From implementation perspective we'll be referring to python class Action that represents Mistral action:

class Action(object):
    @abc.abstractmethod
    def run():
        pass

Method run() here implements action logic (issuing SSH command, sending a message over MQ etc.). All specific action classes must extend class Action and implement abstract method run().

Synchronous/Asynchronous

Mistral action can be synchronous and asynchronous. Synchronous actions act as a regular Python method: when it's called it returns a result upon completion so a caller can immediately use this result. Asynchronous actions don't return a result immediately but rather "launch" an independent activity (e.g. sending a request to an external system to do the heavy job) and when it completes a result becomes know to Mistral.

class Action(object):
    @abc.abstractmethod
    def run():
        pass
    def is_sync():
        return False

Result

Errors

Revert

Dry-Run

Input

Namespaces