Hi Renat,
for me just unclear the following syntacsis:
$.image_id
what is $ in this case? It will be more clear if we can replace $ to
something - any instance with readable name, like global.image_id or
context.image_id.
looks like $ can be the different in different name spaces.
it will be unclear for new users and of course it will be easy when we have
experience with the DSL.
On Wed, Feb 26, 2014 at 11:34 AM, Renat Akhmerov <rakhme...@mirantis.com>wrote:
> Hi team,
>
> I'm currently working on the first version of Data Flow and I would like
> to make sure we all clearly understand how to interpret "parameters" for
> tasks and actions when we declare them in Mistral DSL. I feel like I'm
> getting lost here a little bit. The problem is that we still don't have a
> solid DSL spec since we keep changing our vision (especially after new
> members joined the team). But that may be fine, it's life.
>
> I also have a couple of suggestions that I'd like to discuss with you.
> Sorry if that seems verbose, I'll try to be as concise as possible.
>
> I took a couple of snippets from [1] and put them in here.
>
> # Snippet 1.Services:
> Nova:
> type: REST_API
> parameters:
> baseUrl: $.novaURL
> actions:
> createVM:
> parameters:
> url: /servers/{$.vm_id}
> method: POST
> output:
> select: $.server.id
> store-as: vm_id
> # Snippet 2.Workflow:
> tasks:
> createVM:
> action: Nova:createVM
> on-success: waitForIP
> on-error: sendCreateVMError
>
>
> "$." - handle to workflow execution storage (what we call 'context' now)
> where we keep workflow variables.
>
> Let's say our workflow input is JSON like this:
> {
> "novaURL": "http://localhost:123";,
> "image_id": "123"
> }
>
> *Questions*
>
> So the things that I don't like or am not sure about:
>
> *1*. Task "createVM" needs to use "image_id" but it doesn't have any
> information about it its declaration.
> According to the current vision it should be like
>
> createVM:
> action: Nova:createVM
> parameters:
> image_id: $.image_id
>
> And at runtime "image_id" should be resolved to "123" get passed to action
> and, in fact, be kind of the third parameter along with "url" and "method".
> This is specifically interesting because on one hand we have different types
> of parameters: "url" and "method" for REST_API action define the nature of
> the action itself. But "image_id" on the other hand is a dynamic data coming
> eventually from user input.
>
> *So the question is: do we need to differentiate between these types of
> parameters explicitly and make a part of the specification?*
>
> We also had a notion of "task-parameters" for action declarations which is
> supposed to be used to declare this second type of parameters (dynamic) but
> do we really need it? I guess if we clearly declare input and output at task
> level then actions should be able to use them according to their nature.
>
> *2*. Action declaration "createVM" has section "response" which may not be ok
> in terms of level of abstraction.
>
> My current vision is that actions should not declare how we store the
> result ("output") in execution. Ideally looking at tasks only should give
> us comprehensive understanding of how workflow data flows. So I would move
> "store-as" to task level.
>
> *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).
>
>
> Please let me know your thoughts. We can make required adjustments right
> now.
>
>
> [1] https://etherpad.openstack.org/p/mistral-poc
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Timur,
QA Lead
OpenStack Murano Project
Mirantis Inc
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
