Open Stack

Yes. Guys, thanks for your feedback. I had a conversation with Dmitri today and realized you guys are right here. We should think about building basically a “domain model” which the system operates with and once we built it we should forget that we have some DSL or whatever we used to describe this model (could be other language, for example). Our initial intention actually was different but anyway what you’re saying is valid. Looks like Nikolay agrees with me too and he’s now reworking this commit. Coming up soon.

Renat Akhmerov
@ Mirantis Inc.



On 27 Feb 2014, at 23:36, Manas Kelshikar <manas at stackstorm.com> wrote:

> I looked at the review prior to looking at the discussion and even I was confused by names like DSL*. The way I see it DSL is largely syntatic sugar and therefore it will be good to have a clear separation between DSL and model. The fact that something is defined in a DSL is irrelevant once it crosses mistral API border in effect within mistral itself DSLTask, DSLAction etc are simply description objects and how they were defined does not matter to mistral implementation. 
> 
> Each description object being a recipe to eventually execute a task. We therefore already see these two manifestations in current code i.e. DSLTask(per Nikolay's change) and Task (https://github.com/stackforge/mistral/blob/master/mistral/api/controllers/v1/task.py#L30).
> 
> To me it seems like we only need to agree upon names. Here are my suggestions -
> 
> i)
> DSLTask -> Task
> Task -> TaskInstance
> (Similarly for workflow, action etc.)
> 
> OR
> 
> ii)
> DSLTask -> TaskSpec
> Task -> Task
> (Similarly for workflow, action etc.)
>  
> 
> 
> On Wed, Feb 26, 2014 at 9:31 PM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:
> 
> On 26 Feb 2014, at 22:54, Dmitri Zimine <dz at stackstorm.com> wrote:
> 
>> Based on the terminology from [1], it's not part of the model, but the language that describes the model in the file.
> 
> Sorry, I’m having a hard time trying to understand this phrase :) What do you mean by “model” here? And why should DSL be a part of the model?
> 
>> And theoretically this may be not the only language to express the workflow.
> 
> Sure, from that perspective, for example, JVM has many “DSLs”: Java, Scala, Groovy etc.
> 
>> Once the file is parsed, we operate on model, not on the language.
> 
> How does it influence using term DSL? DSL is, in fact, a user interface. Model is something we build inside a system to process DSL in a more convenient way.
> 
>> 
>> I am afraid we are breaking an abstraction when begin to call things DSLWorkbook or DSLWorkflow. What is the difference between Workbook and DSLWorkbook, and how DSL is relevant here? 
> 
> Prefix “DSL” tells that this exactly matches the structure of an object declared with using DSL. But, for example, a workbook in a database may have (and it has) a different structure better suitable for storing it in a relational model.
> So I’m not sure what you mean by saying “we are breaking an abstraction” here. What abstraction?
> 
>> [1] https://wiki.openstack.org/wiki/Mistral, 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140228/0cef6349/attachment.html>