On 19 Mar 2014, at 16:00, Stan Lagun <sla...@mirantis.com> wrote: > 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).
+1. Makes perfect sense to me. > 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. +1 Renat Akhmerov @ Mirantis Inc. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
