<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 03/19/2014 02:00 AM, Stan Lagun
wrote:<br>
</div>
<blockquote
cite="mid:CAOCoZiaB3zGb-4iUgSW2ksvpndLG0XzmYaf57xWn5Mq_Vb-aKQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Steven,<br>
<br>
</div>
Agree with your opinion on HOT expansion. I see that
inclusion of imperative workflows and ALM would require
major Heat redesign and probably would be impossible
without loosing compatibility with previous HOT syntax.
It would blur Heat mission, confuse current users and
rise a lot of questions what should and what should not
be in Heat. Thats why we chose to built a system on top
of Heat rather then expending HOT.<br>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
+1<br>
<br>
<blockquote
cite="mid:CAOCoZiaB3zGb-4iUgSW2ksvpndLG0XzmYaf57xWn5Mq_Vb-aKQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Now I would like to clarify why have we chosen
imperative approach with DSL.<br>
<br>
</div>
You see a DSL as an alternative to HOT but it is not. DSL is
alternative to Python-encoded </div>
</div>
</div>
</blockquote>
<br>
Not accurate. I see a HOT as one type of DSL. I see the MuranoPL
as an imperative language which is not a DSL. It may have domain
specific aspects, but it is more general purpose in nature.<br>
<br>
<blockquote
cite="mid:CAOCoZiaB3zGb-4iUgSW2ksvpndLG0XzmYaf57xWn5Mq_Vb-aKQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>resources in Heat (heat/engine/resources/*.py). Imagine
how Heat would look like if you let untrusted users to
upload Python plugins to Heat engine and load them on the
fly. Heat resources are written in Python which is
imperative language. So that MuranoPL for the same reason.<br>
<br>
</div>
</div>
</div>
</blockquote>
agree this is bad idea.<br>
<br>
<blockquote
cite="mid:CAOCoZiaB3zGb-4iUgSW2ksvpndLG0XzmYaf57xWn5Mq_Vb-aKQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>We want application authors to be able to express
application deployment and maintenance logic of any
complexity. This may involve communication with 3rd party REST
services (APIs of applications being deployed, external
services like DNS server API, application licensing server
API, billing systems, some hardware component APIs etc) and
internal OpenStack services like Trove, Sahara, Marconi and
others including those that are not incubated yet and those to
come in the future. You cannot have such things in HOT and
when you required to you need to develop custom resource in
Python. Independence on custom plugins is not good for Murano
because they cannot be uploaded by end users and thus he
cannot write application definition that can be imported
to/run on any cloud and need to convince cloud administrator
to install his Python plugin (something that is unimaginable
in real life).<br>
<br>
</div>
</div>
</blockquote>
<br>
I understand. I am not critical of imperative approach for
implementing workflow/ALM. I believe it is mandatory. I hold no
opinion on MuranoPL specifically.<br>
<br>
<blockquote
cite="mid:CAOCoZiaB3zGb-4iUgSW2ksvpndLG0XzmYaf57xWn5Mq_Vb-aKQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Because DSL is a way to write custom resources (in Heats
terminology) it has to be Turing-complete and have all the
characteristics of general-purpose language. It also has to
have domain-specific features because we cannot expect that
DSL users would be as skilled as Heat developers and could
write such resources without knowledge on hosting engine
architecture and internals.<br>
<br>
</div>
</div>
</blockquote>
I understand your point of view, but DSLs are declarative in
nature. I think the problem is that the terminology being used is
incorrect as computer science has defined it :) Just because
MuranoPL has custom stuff for interacting with custom resources,
doesn't mean its a DSL. I can draw a parallel between implementing
arbitrary length integers in a general purpose imperative language.
Said feature is not a DSL, it is a language feature.<br>
<br>
What is being discussed in the context of murano is a language
feature, rather then a DSL.<br>
<br>
<blockquote
cite="mid:CAOCoZiaB3zGb-4iUgSW2ksvpndLG0XzmYaf57xWn5Mq_Vb-aKQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>HOT DSL is declarative because all the imperative stuff is
hardcoded into Heat engine. Thus all is left for HOT is to
define "state of the world" - desired outcome. That is
analogous to Object Model in Murano (see [1]). It is Object
Model that can be compared to HOT, not DSL. As you can see it
not more complex than HOT. Object Model is what end-user
produces in Murano. And he event don't need to write it cause
it can be composed in UI.<br>
<br>
</div>
</div>
</blockquote>
cool<br>
<blockquote
cite="mid:CAOCoZiaB3zGb-4iUgSW2ksvpndLG0XzmYaf57xWn5Mq_Vb-aKQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Now because DSL provides not only a way to write sandboxed
isolated code but also a lot of declarations (classes,
properties, parameters, inheritance and contracts) that are
mostly not present in Python we don't need Parameters or
Output sections in Object Model because all of this can be
inferred from resource (classes) DSL declaration. Another
consequence is that most of the things that can be written
wrong in HOT can be verified on client side by validating
classes' contracts without trying to deploy the stack and then
go through error log debugging. Because all resources'
attributes types their constraints are known in advance (note
that resource attribute may be a reference to another resource
with constraints on that reference like "I want any (regular,
Galera etc) MySQL implementation") UI knows how to correctly
compose the environment and can point out your mistakes at
design time. This is similar to how statically typed languages
like C++/Java can do a lot of validation at compile time
rather then in runtime as in Python.<br>
<br>
</div>
<div>Personally I would love to see many of this features in
HOT. What is your vision on this? What of the mentioned above
can be contributed to Heat? We definitely would like to
integrate more with HOT and eliminate all duplications between
projects. I think that Murano and Heat are complimentary
products that can effectively coexist. Murano provides access
to all HOT features and relies on Heat for most of its
activities. I believe that we need to find an optimal way to
integrate Heat, Murano, Mistral, Solum, Heater, TOSCA, do some
integration between ex-Thermal and Murano Dashboard, be united
regarding Glance usage for metadata and so on. We are okay
with throwing MuranoPL out if the issues it solves would be
addressed by HOT.<br>
<br>
</div>
</div>
</blockquote>
I am not a fan of language features such as inheritance, classes,
properties, etc. I get that for a really general purpose language
like python they are useful. Python has a multi-year learning curve
before writing really "pythonic" code. Hot has a few day learning
curve before writing really "hotonic" code :)<br>
<br>
<blockquote
cite="mid:CAOCoZiaB3zGb-4iUgSW2ksvpndLG0XzmYaf57xWn5Mq_Vb-aKQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>If you have a vision on how HOT can address the same domain
MuranoPL does or any plans for such features in upcoming Heat
releases I would ask you to share it.<br>
</div>
<div><br>
[1] <a moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Object_model">https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Object_model</a><br>
</div>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
I don't think HOT can do these things and I don't think we want HOT
to do these things. I am ok with that, since I don't see the
pushback on having two languages for two different things in
OpenStack. I got from gokrove on iRC today that the rationale for
the pushback was the TC wanted Murano folks to explore how to
integrate better with Heat and possibly the orchestration program.
I don't see HOT as a place where there is an opportunity for scope
expansion. I see instead Murano creating HOT blobs and feeding them
to Heat.<br>
<br>
Regards<br>
-steve<br>
<br>
<blockquote
cite="mid:CAOCoZiaB3zGb-4iUgSW2ksvpndLG0XzmYaf57xWn5Mq_Vb-aKQ@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Mar 19, 2014 at 8:06 AM, Steven
Dake <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Ruslan,<br>
<br>
Some of my thoughts on the evolution of the HOT DSL to date.
<div>
<div class="h5"><br>
<br>
On 03/18/2014 05:32 PM, Ruslan Kamaldinov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is my 2 cents:<br>
<br>
I personally think that evolving Heat/HOT to what
Murano needs for it's use<br>
cases is the best way to make PaaS layer of OpenStack
to look and feel as a<br>
complete and fully integrated solution.<br>
<br>
Standardising these things in a project like TOSCA is
another direction we all<br>
should follow. I think that TOSCA is the place where
developers (like us),<br>
application developers and enterprises can collaborate
to produce a common<br>
standard for application lifecycle management in the
clouds.<br>
<br>
<br>
But before Murano contributors jump into direction of
extending HOT to the goal<br>
of application (or system) lifecycle management, we
need an agreement that this<br>
is the right direction for Heat/HOT/DSL and the
Orchestration program. There are<br>
a lot of use cases that current HOT doesn't seem to be
the right tool to solve.<br>
As it was said before, it's not a problem to
collaborate on extending it those<br>
use cases. I'm just unsure if Heat team would like
these use cases to be solved<br>
with Heat/HOT/DSL. For instance:<br>
- definition of an application which is already
exposed via REST API. Think of<br>
something like Sahara (ex. Savanna) or Trove
developed in-house for internal<br>
company needs. app publishers wouldn't be happy if
they'll be forced to<br>
develop a new resource for Heat<br>
- definition of billing rules for an application<br>
<br>
<br>
If everyone agrees that this is the direction we all
should follow, that we<br>
should expand HOT/DSL to that scope, that HOT should
be the answer on "can you<br>
express it?", then awesome - we can start speaking
about implementation details.<br>
<br>
If it's not the direction these projects should follow
then at least finding<br>
where Heat ends and Murano starts to avoid any
functionality duplication would<br>
be great.<br>
</blockquote>
<br>
</div>
</div>
The HOT DSL for the most part, either by design or
subconscious development choices, enables the application of
Miller's Law[1] in a positive way. HOT as a DSL takes less
then a few hours to learn and use effectively. Its relative
simplicity is its *key* advantage as a DSL. DSL's by their
very nature declare a desired state. It is the
responsibility of the DSL processor to convert that desired
state into reality. On a fundamental level, this is
precisely what Heat does.<br>
<br>
A DSL by its very definition is meant to express a desired
outcome without specifying the intermediate steps. To
express the intermediate steps would require recording state
in variables and offering conditional operations on those
variables. This implies individual steps in the processing
of the input to the language. If HOT were to add these
sorts of features, it would no longer be a DSL, but a
general purpose language (perhaps less general purpose then
python or C). A DSL is by definition a declarative
language. I don't like the idea of expanding the scope of
HOT to add an imperative model of operation.<br>
<br>
Learning imperative languages takes inordinately more time
and brainpower then learning declarative languages,
especially those which generally follow the advantages
provided by languages operating inside the constraints of
Miller's Law. We want Heat to be dead simple to explain and
learn. Realistically I'd like folks to be able to write a
template in under an hour with 15 minutes of explanation,
and I think we have hit that mark.<br>
<br>
The idea of expanding the scope of the Heat APIs and engine
to include ALM and Workflow don't make sense to me from an
engineering perspective. It over-complicates the code base.
I know we have already covered those thoughts in detail on
the mailing list previously and the Murano folks agree that
is a bad idea.<br>
<br>
I see a parallel between expanding the scope of HOT to
support ALM and Workflow and expanding the scope of the
heat-engine in the same fashion that is not appealing. What
would make more sense is to follow the general laws of Unix
(do one thing, do it well) and layer these other possibly
imperative languages on top of Heat using HOT and the Heat
APIs to implement such imperative programming models. Then
if someone really wanted to invest in the complexity of ALM
or Workflow, they may be more willing to invest in learning
the complexity of a new imperative programming language.<br>
<br>
My personal opinion is expanding the scope of HOT to include
imperative programming models is not desirable for Heat in
isolation. I understand such an outcome may be appealing as
a holistic approach to handling the entire orchestration
space, but feel the costs of learning an imperative model
for HOT do not pay for the advantages of having only one
language to program all the things.<br>
<br>
I see no issue with HOT remaining simple and tidy focused
entirely on orchestration (taking a desired state and
converting that into reality) with some other imperative
language layered on top to handle workflow and ALM. I
believe this separation of concerns is best for OpenStack
and should be the preferred development path.<br>
<br>
Regards,<br>
-steve<br>
<br>
[1] <a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two"
target="_blank">http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two</a>
<div class="HOEnZb">
<div class="h5">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Ruslan<br>
<br>
On Wed, Mar 19, 2014 at 2:07 AM, Keith Bray <<a
moz-do-not-send="true"
href="mailto:keith.bray@rackspace.com"
target="_blank">keith.bray@rackspace.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Georgy,<br>
<br>
In consideration of the "can you express it" instead
of the "who will<br>
generate it," I see Heat's HOT evolving to support
the expression of complex<br>
multi-tier architectures and applications (I would
argue you can already do<br>
this today, perhaps with some additional features
desired, e.g. Ability to<br>
define cloud workflows and workflow execution rules
which could come when we<br>
have a workflow service like Mistral). Therefore, I
would encourage Murano<br>
contributors to consider whether they can help make
Heat sufficiently cover<br>
desired use cases. I have never viewed Heat
templates as isolated<br>
components of a multi-tier architecture. Instead, a
single template or a<br>
combination of master/subordinate templates together
(using references,<br>
nesting, or inclusion) could express the complete
architecture, both<br>
infrastructure and applications.<br>
<br>
If I've read your previous comments and threads
correctly, you desire a way<br>
to express System Lifecycle Management across
multiple related applications<br>
or components, whereby you view the System as a
grouping of independently<br>
developed and/or deployed (but systematically
related) "components," whereby<br>
you view Components as individual disconnected Heat
templates that<br>
independently describe different application stacks
of the System. Did I<br>
get that correct? If so, perhaps the discussion
here is one of "scope" of<br>
what can or should be expressed in a Heat template.
Is it correct to state<br>
that your argument is that a separate system (such
as Murano) should be used<br>
to express System Lifecycle Management as I've
defined it here? If so, why<br>
could we not use the Heat DSL to also define the
System? The System<br>
definition could be logically separated out into its
own text file... But,<br>
we'd have a common DSL syntax and semantics for both
lower level and higher<br>
level component interaction (a building block effect
of sorts).<br>
<br>
As for "who will generate it," ( with "it" being the
Heat multi-tier<br>
application/infrastructure definition) I think that
question will go through<br>
a lot more evolution and could be any number of
sources: e.g. Solum, Murano,<br>
Horizon, Template Author with a text editor, etc.<br>
<br>
Basically, I'm a +1 for as few DSLs as possible. I
support the position that<br>
we should evolve HOT if needed vs. having two
separate DSLs that are both<br>
related to expressing application and infrastructure
semantics.<br>
<br>
Workflow is quite interesting ... Should we be able
to express imperative<br>
workflow semantics in HOT? Or, should we only be
able to declare workflow<br>
configurations that get configured in a service like
Mistral whereby<br>
Mistral's execution of a workflow may need to invoke
Heat hooks or Stack<br>
Updates? Or, some other solution?<br>
<br>
I look forward to a design discussion on all this at
the summit... This is<br>
fun stuff to think about!<br>
<br>
-Keith<br>
<br>
From: Georgy Okrokvertskhov <<a
moz-do-not-send="true"
href="mailto:gokrokvertskhov@mirantis.com"
target="_blank">gokrokvertskhov@mirantis.com</a>><br>
<br>
Reply-To: "OpenStack Development Mailing List (not
for usage questions)"<br>
<<a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org"
target="_blank">openstack-dev@lists.openstack.org</a>><br>
Date: Tuesday, March 18, 2014 1:49 PM<br>
<br>
To: "OpenStack Development Mailing List (not for
usage questions)"<br>
<<a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org"
target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL
questions?<br>
<br>
I see this in the following way - who will generate
HOT template for my<br>
complex multi-tier applications when I have only
templates for components?<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div dir="ltr"><span
style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times
New
Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span
style="font-family:arial;font-size:small">Sincerely yours<br>
Stanislav (Stan) Lagun<br>
Senior Developer<br>
Mirantis</span></span><br>
<span
style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times
New
Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span
style="font-family:arial;font-size:small"><span
style="font-size:10.0pt;font-family:"Arial","sans-serif""
lang="EN-US">35b/3, Vorontsovskaya
St.</span><br>
Moscow, Russia<br>
Skype: stanlagun<br>
<a moz-do-not-send="true" href="http://www.mirantis.com/"
target="_blank">www.mirantis.com</a><br>
<a moz-do-not-send="true"
href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a></span></span></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>