Open Stack

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