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 <ma...@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" <rakhme...@mirantis.com> wrote: > >> Alright, good input Manas, appreciate. >> >> My comments are below... >> >> On 06 Mar 2014, at 10:47, Manas Kelshikar <ma...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best Regards, Nikolay
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev