(I added a couple of tags to the subject; hope this doesn't screw up
anyone's threading.)
On 09/03/14 16:26, Joshua Harlow wrote:
I'd be very interested in knowing the resource controls u plan to add.
Memory, CPU...
I'm still trying to figure out where something like
https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.demoApp.DemoInstance/manifest.yaml
would be beneficial, why not just spend effort sand boxing lua,
python... Instead of spending effort on creating a new language and then
having to sandbox it as well... Especially if u picked languages that
are made to be sandboxed from the start (not python)...
-1 to using a full-blown programming language like Python over a DSL, but...
Who is going to train people on muranoPL, write language books and
tutorials when the same amount of work has already been done for 10+
years for other languages....
I fail to see where muranoPL is a DSL when it contains a full language
already with functions, objects, namespaces, conditionals... (what is
the domain of it?), maybe I'm just confused though (quite possible, haha).
...I'm inclined to agree with this. Whenever you find yourself
implementing a Turing-complete Object-Oriented DSL... well, you'd at
least want to stop and think very carefully about whether you might have
taken a wrong turn somewhere.
Does this not seem awkward to anyone else??
It does seem really awkward to me (and not just because of all the
$signs), because it's duplicating basically all of the functionality of
Heat. e.g. in MuranoPL you have:
Properties:
name:
Contract: $.string().notNull()
whereas in HOT this would be:
parameters:
name:
type: string
constraints:
- length: {min: 1}
In MuranoPL you reference it using "$this.name", vs. HOT using
"{get_param: name}".
Note that HOT (a) already exists in OpenStack, and (b) is being
developed in conjunction with TOSCA folks to ensure easy translation
to/from TOSCA Simple Profile YAML rendering.
Looking at e.g. [1], more or less everything in here can be done
already inside a Heat template, using get_file and str_replace.
It sounds like this is a DSL in which you write everything imperatively,
then it gets converted behind the scenes into a declarative model in a
completely different language (but not using any of the advanced
features of that language) and passed to Heat, which turns it back into
a workflow to execute. That seems bizarre to me. Surely Murano should be
focusing on filling the gaps in Heat, rather than reimplementing it in a
different paradigm?
What I'm imagining here is something along the lines of:
- Heat implements hooks to customise its workflows, as proposed in [2], [3].
- Deployments are defined declaratively using HOT syntax.
- Workflows - to wrap the deployment operations, to customise the
deployment and to perform lifecycle operations like backups - are
defined using a Mistral DSL (I assume this exists already? I haven't
looked into it).
- Murano provides a way to bundle the various workflow definitions, HOT
models, and other files into an application package.
Can anybody enlighten me as to what features would be missing from this
that would warrant creating a new programming language?
thanks,
Zane.
[1]
https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.demoApp.DemoInstance/manifest.yaml
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026329.html
[3]
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030228.html
Sent from my really tiny device...
On Mar 8, 2014, at 10:44 PM, "Stan Lagun" <sla...@mirantis.com
<mailto:sla...@mirantis.com>> wrote:
First of all MuranoPL is not a host but hosted language. It never
intended to replace Python and if Python can do the job it is probably
better than MuranoPL for that job.
The problem with Python is that you cannot have Python code as a part
of your DSL if you need to evaluate that DSL on server-side. Using
Python's eval() is not secure. And you don't have enough control on
what evaled code is allowed to do. MuranoPL on the contrary are fully
sandboxed. You have absolute control over what functions/methods/APIs
are exposed to DSL and DSL code can do nothing except for what it
allowed to do. Besides you typically do want your DSL to be
domain-specific so general-purpose language like Python can be suboptimal.
I don't say MuranoPL is good for all projects. It has many
Murano-specific things after all. In most cases you don't need all
those OOP features that MuranoPL has. But the code organization, how
it uses YAML, block structures and especially YAQL expressions can be
of a great value to many projects
For examples of MuranoPL classes you can browse
https://github.com/istalker2/MuranoDsl/tree/master/meta folder. This
is my private repository that I was using to develop PoC for MuranoPL
engine. We are on the way to create production-quality implementation
with unit-tests etc. in regular Murano repositories on stackforge
On Sun, Mar 9, 2014 at 7:33 AM, Joshua Harlow <harlo...@yahoo-inc.com
<mailto:harlo...@yahoo-inc.com>> wrote:
To continue from other thread....
"""
Personally I believe that YAQL-based DSLs similar (but probably
simlet than) MuranoPL can be of a great value for many OpenStack
projects that have DSLs of different kind. Murano for App
Catatalog, Mistral for workflows, Heat for HOT templates,
Ceilometer for alarms & counter aggregation rules, Nova for
customizable resource scheduling and probably many more.
"""
Isn't python a better host language for said DSLs than muranoPL? I
am still pretty weary of a DSL that starts to grow so many
features to encompass other DSLs since then it's not really a DSL
but a non-DSL, and we already have one that everyone is familiar
with (python).
Are there any good examples if muranoPL that I can look at that
take advantage of muranoPL classes, functions, namespaces which
can be compared to there python equivalents. Has such an
analysis/evaluation been done?
Sent from my really tiny device...
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com <http://www.mirantis.com/>
sla...@mirantis.com <mailto:sla...@mirantis.com>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto: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
