Hi, Renat!
*Suggestions* > *1*. Define "input" and "output" at task level like this: > createVM: > input: > image_id: $.image_id > output: vm_id > Where "output: vm_id" is basically a replacement for "store-as: vm_id" at > action level, i.e. it's a hint to Mistral to store the output of this task > under "vm_id" key in execution context. Again, the idea is to define task > and action responsibilities more strictly: > > - *Task is a high-level workflow building block which defines workflow > logical step and how it modifies workflow data. Task doesn't contain > technical details on how it's implemented.* > > > - *Action is an implementor of the workflow logical step defined by a > task. Action defines specific algorithm of how task is implemented.* > > > *2*. User "parameters" only for actions to specify their additional > properties influencing their nature (like method for HTTP actions). Just clarify your thoughts: - All static keys and parameters should be in actions - All dynamic keys and parameters should be in tasks block - We may use our context to define some parameters in action or task And, yes, I think it is a good idea to differentiate this. It is become easier
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
