Ok, good! Renat Akhmerov @ Mirantis Inc.
On 06 Mar 2014, at 15:25, Nikolay Makhotkin <[email protected]> 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 <[email protected]> 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" <[email protected]> wrote: > Alright, good input Manas, appreciate. > > My comments are below... > > On 06 Mar 2014, at 10:47, Manas Kelshikar <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best Regards, > Nikolay > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
