Open Stack

On 14 Mar 2014, at 05:00, Dmitri Zimine <dz at stackstorm.com> wrote:

> - Async actions: how do results of async action communicates back? 
> My understanding it it assumes that the remote system will call back to mistral with action execution id, it's on the engine to call-back, and action needs to let the engine know to expect call-back. Let's put the explanation here. 

Yes. When I was writing this I thought it was a little bit out of the scope. Basically, in API there’s a method which can be used to deliver a result once it’s been calculated. And then engine does what’s needed to update task state and advance the workflow. Currently, it’s only possible to do it via REST API and we also have a requirement to do it via MQ (it can be configurable).

> 	- is_sync() - consider using an attribute instead -  @mistral.async

Well, I had an idea that it may depend on how a particular action instance is parameterized (in other words, a dynamic thing rather than static property). It would just give more flexibility

> 	- can we think of a way to unify sync and async actions from engine's standpoint? So that we don't special-case it in the engine?

To be precise, engine has no knowledge about it. Only executor does and it has to but the difference is pretty small. In case if action is sync it should just call the API method I mentioned above to deliver action result. When we finish our BPs related to oslo.messaging it’ll be working over it.

> @ Joshua - does something similar exists in TaskFlow already?

As far as I know, it doesn’t exist in TaskFlow but I may be wrong.. 

> - def dry_run() - maybe name "test", let's stress that this method should return a representative sample output. 

Ok, I like that. Will change this part.

> - Input - need a facility to declare, validate and list input parameters. Like VALID_KEYS=['url', 'parameters''] , def validate(): 
> 
> - class HTTPAction(object):
>     def __init__(self, url, params, method, headers, body):
> Not happy about declaring parameters explicitly. How about using * args **kvargs, or 'parameters' dictionary? 

Yes, these two items are related. I think it’s a matter of responsibility distribution. Whether we want validation to happen in action factory or in action itself. I tend to agree with you on this one that action class should be responsible itself for validation. Let’s think more through that.

> - DSL In-Place Declaration - I did minor edits in the section, please check. 

Ok. Thanks.


Renat Akhmerov
@ Mirantis Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140314/772a6069/attachment.html>