Open Stack

> I'd be very interested in knowing the resource controls u plan to add.
Memory, CPU...
We haven't discussed it yet. Any suggestions are welcomed

> I'm still trying to figure out where something like
https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.demoApp.DemoInstance/manifest.yamlwould
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. See my detailed answer in Mistral thread why haven't we used any of
those languages. There are many reasons besides sandboxing.

2. You don't need to sandbox MuranoPL. Sandboxing is restricting some
operations. In MuranoPL ALL operations (including operators in expressions,
functions, methods etc.) are just those that you explicitly provided. So
there is nothing to restrict. There are no builtins that throw
AccessViolationError

3. Most of the value of MuranoPL comes not form the workflow code but from
class declarations. In all OOP languages classes are just a convenient to
organize your code. There are classes that represent real-life objects and
classes that are nothing more than data-structures, DTOs etc. In Murano
classes in MuranoPL are deployable entities like Heat resources application
components, services etc. In dashboard UI user works with those entities.
He (in UI!) creates instances of those classes, fills their property
values, binds objects together (assigns on object to a property of
another). And this is done without even a single MuranoPL line being
executed! That is possible because everything in MuranoPL is a subject to
declaration and because it is just plain YAML anyone can easily extract
those declarations from MuranoPL classes.
Now suppose it was Python instead of MuranoPL. Then you would have to parse
*.py files to get list of declared classes (without executing anything).
Suppose that you managed to solve this somehow. Probably you wrote regexp
that finds all class declarations it text files. Are you done? No! There
are no properties (attributes) declarations in Python. You cannot infer all
possible class attributes just from class declaration. You can try to parse
__init__ method to find attribute initialization code but then you find
that you cannot infer property types. You would not know what values does
class expect in those attributes, what are constraints etc. Besides there
are plenty of ways to fool such naive algorithms. Classes can be created
using type() built-in function without declarations at all. Attributes may
be initialized anywhere. Everything can be made in runtime.
As you can see Python is not good for the task. Ans all this true for all
of the languages you mentioned. The reason is fundamental - all of those
languages are dynamic.
So maybe you can take some statically-typed language like C++ or Java to do
the job? Again, no! There are other problems with those type of languages.
Have you ever seen statically-typed embeddable language? Those language
require compilation and linker, binary distribution of classes, handling of
versioning problems, dependencies on 3-rd party libraries etc. This is the
hell you don't want to step in. But even in statically typed languages
there are no contracts. You know the list of properties and their types.
But knowing that class foo has property bar of type int doesn't give a clue
if value if 10 is okay for that property.

Now I admit that we could probably spend a year of development and try to
implement this on type Java with custom wrapping and heavy usage of
decorators, embed somehow JVM into python process, do all possible
sandboxing and then get a Frankenstein that nobody in OpenStack community
would like or accept.

My point here is that there is no language in the world that was designed
for external object composition that is in Murano. No language in the world
was design so that there would be huge repository of classes but no single
control point, no main project, no trust between different classes. There
is no language with tree-like heap organization (each object has single
owner object). This what makes MuranoPL domain-specific and not
deployments. There are no such languages not because nobody that smart to
create them but because nobody needed to do so. Because MuranoPL is
domain-specific unlike Python or Java.

MuranoPL does contain many constructs that can be found in general-purpose
languages but that doesn't make it general-purpose!


> 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....
Let me say that most of MuranoPL audience are bash-developers that know Lua
to the same level they know MuranoPL :)

In Mirantis we deed interesting experiment. We asked several deployment
engineers that were not involved in MuranoPL creation and knew nothing
about it beforehand to write some application manifests using MuranoPL. We
gave them 10-minute introduction, link to DSL documentation blueprint and
examples in my github repository (you've seen both of them). The link above
to DemoInstance manifest points to the class that was created by one of
those guys. It took them several days to get used to it. But they never
even used Python before! And the feedback was very positive.

I don't really see a problem writing tutorials or even a book. Learning new
framework like TaskFlow is nowhere easier than learning DSL. Anyway you
need to learn something to start using new technology. There are hundreds
of DSL languages that are used in production and I don't feel like having
one more language is really a problem




On Mon, Mar 10, 2014 at 12:26 AM, Joshua Harlow <harlowja at yahoo-inc.com>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.yamlwould 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)...
>
>  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).
>
>  Does this not seem awkward to anyone else??
>
> Sent from my really tiny device...
>
> On Mar 8, 2014, at 10:44 PM, "Stan Lagun" <slagun at 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 <harlowja at 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 at 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
> slagun at mirantis.com
>
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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
slagun at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140310/96087e74/attachment.html>