Open Stack

On 27 Feb 2014, at 08:11, Dmitri Zimine <dz at stackstorm.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/1e86042c/attachment.html>