Ruslan,
Some of my thoughts on the evolution of the HOT DSL to date.
On 03/18/2014 05:32 PM, Ruslan Kamaldinov wrote:
Here is my 2 cents:
I personally think that evolving Heat/HOT to what Murano needs for it's use
cases is the best way to make PaaS layer of OpenStack to look and feel as a
complete and fully integrated solution.
Standardising these things in a project like TOSCA is another direction we all
should follow. I think that TOSCA is the place where developers (like us),
application developers and enterprises can collaborate to produce a common
standard for application lifecycle management in the clouds.
But before Murano contributors jump into direction of extending HOT to the goal
of application (or system) lifecycle management, we need an agreement that this
is the right direction for Heat/HOT/DSL and the Orchestration program. There are
a lot of use cases that current HOT doesn't seem to be the right tool to solve.
As it was said before, it's not a problem to collaborate on extending it those
use cases. I'm just unsure if Heat team would like these use cases to be solved
with Heat/HOT/DSL. For instance:
- definition of an application which is already exposed via REST API. Think of
something like Sahara (ex. Savanna) or Trove developed in-house for internal
company needs. app publishers wouldn't be happy if they'll be forced to
develop a new resource for Heat
- definition of billing rules for an application
If everyone agrees that this is the direction we all should follow, that we
should expand HOT/DSL to that scope, that HOT should be the answer on "can you
express it?", then awesome - we can start speaking about implementation details.
If it's not the direction these projects should follow then at least finding
where Heat ends and Murano starts to avoid any functionality duplication would
be great.
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.
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.
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.
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.
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.
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.
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.
Regards,
-steve
[1] http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
Thanks,
Ruslan
On Wed, Mar 19, 2014 at 2:07 AM, Keith Bray <keith.b...@rackspace.com> wrote:
Georgy,
In consideration of the "can you express it" instead of the "who will
generate it," I see Heat's HOT evolving to support the expression of complex
multi-tier architectures and applications (I would argue you can already do
this today, perhaps with some additional features desired, e.g. Ability to
define cloud workflows and workflow execution rules which could come when we
have a workflow service like Mistral). Therefore, I would encourage Murano
contributors to consider whether they can help make Heat sufficiently cover
desired use cases. I have never viewed Heat templates as isolated
components of a multi-tier architecture. Instead, a single template or a
combination of master/subordinate templates together (using references,
nesting, or inclusion) could express the complete architecture, both
infrastructure and applications.
If I've read your previous comments and threads correctly, you desire a way
to express System Lifecycle Management across multiple related applications
or components, whereby you view the System as a grouping of independently
developed and/or deployed (but systematically related) "components," whereby
you view Components as individual disconnected Heat templates that
independently describe different application stacks of the System. Did I
get that correct? If so, perhaps the discussion here is one of "scope" of
what can or should be expressed in a Heat template. Is it correct to state
that your argument is that a separate system (such as Murano) should be used
to express System Lifecycle Management as I've defined it here? If so, why
could we not use the Heat DSL to also define the System? The System
definition could be logically separated out into its own text file... But,
we'd have a common DSL syntax and semantics for both lower level and higher
level component interaction (a building block effect of sorts).
As for "who will generate it," ( with "it" being the Heat multi-tier
application/infrastructure definition) I think that question will go through
a lot more evolution and could be any number of sources: e.g. Solum, Murano,
Horizon, Template Author with a text editor, etc.
Basically, I'm a +1 for as few DSLs as possible. I support the position that
we should evolve HOT if needed vs. having two separate DSLs that are both
related to expressing application and infrastructure semantics.
Workflow is quite interesting ... Should we be able to express imperative
workflow semantics in HOT? Or, should we only be able to declare workflow
configurations that get configured in a service like Mistral whereby
Mistral's execution of a workflow may need to invoke Heat hooks or Stack
Updates? Or, some other solution?
I look forward to a design discussion on all this at the summit... This is
fun stuff to think about!
-Keith
From: Georgy Okrokvertskhov <gokrokvertsk...@mirantis.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: Tuesday, March 18, 2014 1:49 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
I see this in the following way - who will generate HOT template for my
complex multi-tier applications when I have only templates for components?
_______________________________________________
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
