Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/afa02ca3/attachment.html>