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<mailto:gokrokvertsk...@mirantis.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto: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<mailto: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
