Open Stack

Agree, 

with one detail: make it explicit -  task(task_name). 

res - we often see folks confused by result of what (action, task, workflow) although we cleaned up our lingo: action-output, task-result, workflow-output…. but still worth being explicit.

And full result is being thought as the root context $.

Publishing to global context may be ok for now, IMO.

DZ>

On Sep 2, 2015, at 4:16 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:

> Hi,
> 
> I’d like to propose a few changes after transition to yaql 1.0:
> 
> We already moved from using “$.__execution” in DSL to "execution()” and from “$.__env” to “env()” where “execution()” and “env()" are registered yaql functions. We had to do it because double underscored are prohibited in the new yaql.
> 
> 
> In the spirit of these changes I’m proposing a similar change for addressing task result in Mistral DSL.
> 
> Currently we have the syntax “$.task_name” that we can use in yaql expressions to refer to corresponding task result. The current implementation is of that is kind of tricky and, IMO, conceptually wrong because referencing this kind of key leads to DB read operation that’s requried to fetch task result (it may be big as megabytes so it can’t be stored in workflow context all the time. In other words, we create a dictionary with side effect and change the initial semantics of dictionary. Along with mentioned trickiness of this approach it’s not convenient, for example, to debug the code because we can accidentally cause a DB operation. 
> 
> So the solution I’m proposing is to have an explicit yaql function called “res” or “result” to extract task result.
> 
> res() - extracts the result of the current task, i.e. in “publish” clause.
> res(‘task_name’) - extracts the result of the task with the specified name. Can also be used in “publish” clause, if needed
> 
> This approach seems more flexible (cause we can add any other functions w/o having to make significant changes in WF engine) and expressive because user won’t confuse $.task_name with addressing a regular workflow context variable.
> 
> Of course, this to some extent breaks backwards compatibility. But we already changed yaql version which was necessary anyway so it seems like a good time to do it.
> 
> I’d very much like to have your input on this.
> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150902/6c7decf5/attachment.html>