On 27 Feb 2014, at 08:11, Dmitri Zimine <[email protected]> wrote:
> As a learning exercise, I was trying to extract the intend behind the DSL and
> current code. Giving that many things are still moving, I filled up the
> blanks with imagination. Here is my understanding on where you are going:
>
> https://docs.google.com/a/stackstorm.com/drawings/d/1qBxrmQ8F7YFlz930zEbHKUxgzc3ty7JrlmoTR5TxQlo/edit
>
> Is it where we are going?
> Can we use it to bring us the new team members to your understanding?
> Please comment here or right on the document.
Yes, Dmitri. This is correct. The picture you created seems to express the
intention.
The reasons why we decided to do this are:
We don’t have any validation now when parsing DSL. It means that incorrect part
of DSL may only get revealed, for example, hours later after workflow started
when Mistral process a particular action and sees that something is missing.
So far the whole work with dsl has been based on having a dictionary consisting
of other nested dictionaries that reflect exactly what we have in YAML and
hence we’ve had to do something like
wb_dsl[‘Workflow’][‘tasks’][task_name][‘action’] to access something. It just
looks ugly to use string literals all over the code: it’s fragile, we need to
remember everything about DSL structure and so on.
It seems to be a good idea to have classes in the code that reflect DSL
structure so that we can always see how it looks like and use it in development
process instead of keeping everything in the head. In other words, from code
perspective these classes play the role of DSL specification (like DTOs reflect
interprocess communication protocols or rest resources that we define
explicitly in API layer).
It will be much easier to do refactoring having these classes. Although Python
is a dynamic language and refactoring support is very limited due to
fundamental reasons IDEs can still help with lots of things.
> Nikolay's recent refactoring seems to be going in this direction :
> https://review.openstack.org/#/c/75888/
Yes, we have blueprints
https://blueprints.launchpad.net/mistral/+spec/mistral-dsl-model
https://blueprints.launchpad.net/mistral/+spec/mistral-dsl-validation
which were registered to address the problems I mentioned above. I guess we
should put more information in the first one though.
> We are missing a separation of ActionSpec and ActionData. They have distinct
> roles. First - action spec, from Service/actions section - defines the new
> action declaratively from existing action. Second - action data from
> Workflow/tasks/task - defines parameters for a particular action instance.
There’s still a lot of work left on actions including the ability to write
custom actions and plug them in to Mistral. What you call ActionSpec, in my
understanding, just an implementation of BaseAction class that we have now (I
would rename it just to Action) that has a constructor with all parameters
required by this action and its implementation logic. ActionData is what we
declare in DSL.
Renat Akhmerov
@Mistral Inc
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
