|
|
| (51 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | == Step 0: rename __call__ to execute ==
| + | '''Revised on:''' {{REVISIONMONTH1}}/{{REVISIONDAY}}/{{REVISIONYEAR}} by {{REVISIONUSER}} |
| | | | |
| − | Just do that, __call__ looks too magical.
| + | The page was moved to developers documentation: http://docs.openstack.org/developer/taskflow/arguments_and_results.html |
| − | | |
| − | == Required task arguments ==
| |
| − | | |
| − | Required arguments MUST be passed to task when it is executed, as
| |
| − | <code>execute</code> method arguments.
| |
| − | | |
| − | Required arguments list should be inferred from <code>execute</code> method
| |
| − | signature, like we already do for <code>@task</code> decorator.
| |
| − | | |
| − | We also need provide a way to override it, to make adaptors like FunctorTask
| |
| − | possible.
| |
| − | | |
| − | == Task results ==
| |
| − | | |
| − | Task result is what task returns from <code>execute</code> method. It is saved
| |
| − | in persistence layer with task details and is passed to <code>revert</code> method when/if
| |
| − | task is reverted.
| |
| − | | |
| − | To map result of already run task to task arguments, we must name task results
| |
| − | This names are used as a key to storage ('memory' in TaskMachine terms) access
| |
| − | | |
| − | But we can't infer name from task signature, result naming should be explicit.
| |
| − | To make solution more symmetric to inferring names from signature, we propose
| |
| − | to use decorator on execute method for that.
| |
| − | | |
| − | For example:
| |
| − | | |
| − | class MyTask(task.Task):
| |
| − | @decorators.returns('foo', 'bar', 'baz'):
| |
| − | def execute(self, context, spam, eggs):
| |
| − | return 4, 8, 15 # 23 42
| |
| − | | |
| − | This required arguments are <code>context</code>, <code>spam</code> and
| |
| − | <code>eggs</code>; it returns three values: <code>foo</code>, <code>bar</code>
| |
| − | and <code>baz</code>. From it's implementation it is easy to see that
| |
| − | <code>foo</code> will be equal to 4, <code>bar</code> to 8 and <code>baz</code>
| |
| − | to 15.
| |
| − | | |
| − | Again, we need provide a way to override it, to make adaptors like FunctorTask
| |
| − | possible.
| |
| − | | |
| − | == Argument and result rebinding ==
| |
| − | | |
| − | It is sometimes useful to save task result with name other then specified in
| |
| − | it. This can be a part of flow definition.
| |
| − | | |
| − | FIXME: short example with good explanation.
| |
| − | | |
| − | == Optional task arguments ==
| |
| − | | |
| − | Task gets optional arguments as keyword arguments to <code>execute</code> (if
| |
| − | task wants optional arguments, <code>**kwargs</code> should be added to
| |
| − | <code>execute</code> argument list.
| |
| − | | |
| − | There is no need to specify what optional arguments task accepts, also it
| |
| − | definitely worth to document them.
| |
| − | | |
| − | Which optional arguments are passed to task
| |
| − | is specified in flow definition, in the same way as it is done
| |
| − | for argument rebinding: add extra arguments to list or dict and these argument
| |
| − | will be fetched from storage and passed to <code>execute</code> as keyword
| |
| − | arguments.
| |
| − | | |
| − | FIXME: short example with good explanation.
| |
