Open Stack

Ok, good!

Renat Akhmerov
@ Mirantis Inc.



On 06 Mar 2014, at 15:25, Nikolay Makhotkin <nmakhotkin at mirantis.com> wrote:

> Manas, Renat, no problem :)
> 
> The commit is sent already - https://review.openstack.org/#/c/75888/
> 
> 
> On Thu, Mar 6, 2014 at 12:14 PM, Manas Kelshikar <manas at stackstorm.com> wrote:
> I agree, let's rename data to spec and unblock the check-in.
> 
> Nikolay - Sorry for the trouble :)
> 
> On Mar 5, 2014 10:17 PM, "Renat Akhmerov" <rakhmerov at mirantis.com> wrote:
> Alright, good input Manas, appreciate.
> 
> My comments are below...
> 
> On 06 Mar 2014, at 10:47, Manas Kelshikar <manas at stackstorm.com> wrote:
>> Do we have better ideas on how to work with DSL? A good mental exercise here would be to imagine that we have more than one DSL, not only YAML but say XML. How would it change the picture?
>> [Manas] As long as we form an abstraction between the DSL format i.e. YAML/XML and it consumption we will be able to move between various formats. (wishful) My personal preference is to not even have DSL show up anywhere in Mistral code apart from take it as input and transforming into this first level specification model - I know this is not the current state.
> 
> Totally agree with your point. That’s what we’re trying to achieve.
>> How can we clearly distinguish between these two models so that it wouldn’t be confusing?
>> Do we have a better naming in mind?
>> [Manas] I think we all would agree that the best approach is to have precise naming.
>> 
>> I see your point of de-normalizing the dsl data into respective db model objects.
>> 
>> In a previous email I suggested using *Spec. I will try to build on this -
>> 1. Everything specified via the YAML input is a specification or definition or template. Therefore I suggest we suffix all these types with Spec/Definition/Template. So TaskSpec/TaskDefinition/TaskTemplate etc.. As per the latest change these are TaskData ... ActionData. 
> 
> After all the time I spent thinking about it I would choose Spec suffix since it’s short and expresses the intention well enough. In conjunction with “workbook” package name it would look very nice (basically we get specification of workbook which is what we’re talking about, right?)
> 
> So if you agree then let’s change to TaskSpec, ActionSpec etc. Nikolay, sorry for making you change this patch again and again :) But it’s really important and going to have a long-term effect at the entire system.
> 
>> 2. As per current impl the YAML is stored as a key-value in the DB. This is fine since that is front-ended by objects that Nikolay has introduced. e.g. TaskData, ActionData etc.
> 
> Yep, right. The only thing I would suggest is to avoid DB fields like “task_dsl” like we have now. The alternative could be “task_spec”.
> 
>> 3. As per my thinking a model object that ends up in the DB or a model object that is in memory all can reside in the same module. I view persistence as an orthogonal concern so no real reason to distinguish the module names of the two set of models. If we do choose to distinguish as per latest change i.e. mistral/workbook that works too.
> 
> Sorry, I believe I wasn’t clear enough on this thing. I think we shouldn’t have these two models in the same package since what I meant by “DB model” is actually “execution” and “task” that carry workflow runtime information and refer to a particular execution (we could also call it “session”). So my point is that these are fundamentally different types of models. The best analogy that comes to my mind is the relationship “class -> instance” where in our case “class = Specification" (TaskSpec etc.) and “instance = Execution/Task”. Does it make any sense?
> 
>> @Nikolay - I am generally ok with the approach. I hope that this helps clarify my thinking and perception. Please ask more questions.
>> 
>> Overall I like the approach of formalizing the 2 models. I am ok with current state of the review and have laid out my preferences.
> 
> I like the current state of this patch. The only thing I would do is renaming “Data” to “Spec”.
> 
> Thank you.
> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> 
> 
> _______________________________________________
> 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
> 
> 
> 
> 
> -- 
> Best Regards,
> Nikolay
> _______________________________________________
> 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/20140306/8f440526/attachment.html>