We touched this on review https://review.openstack.org/#/c/73205/, and fixed a
bit, bringing it up here to further discuss at slightly higher level.
Let's go over a tiny bit of YAML definition, clarifying terminology on the way.
Current DSL snippet:
actions:
my-action
parameters:
foo: bar
response: # just agreed to change to 'results'
select: '$.server_id'
store_as: v1
In the code, we refer to action.result_helper
1) Note that response is not exactly a parameter. It doesn't doesn't refer to
data. It's (query, variable) pairs, that are used to parse the results and
post data to global context [1]. The terms response, or result, do not reflect
what is actually happening here. Suggestions? Save? Publish? Result Handler?
2) Whichever name we use for this output transformer, shall it be under
parameters?
3) how do we call action/task parameters? Think 'model' (which reflects in
yaml, code, docs, talk, etc.)
input and output? (+1)
in and out? (-1)
request and response? (-1) good for WebServices but not generic enough
parameters and results? (ok)
4) Syntax simplification: can we drop 'parameters' keyword? Anything under
action is action parameters, unless it's a reserved keyword, which the
implementation can parse out.
actions:
my-action
foo: bar
task-parameters: # not a keyword, specific to REST_API
flavor_id:
image_id:
publish: # keyword
select: '$.server_id'
store_as: v1
[1] Save discussing the way we work with data flow, and talking alternatives,
to the next time.
DZ.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
