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
