Open Stack

Hi Alex,

I'm two hands up for making developers life easier. However we should
remember that MuranoPL is not a scripting language and not a Python
replacement. There's very little point in writing Hello Word on MuranoPL.
And once you go for even the simplest app possible you will still have to
have OpenStack installed, manifest file written, class created etc. So the
only use case that I see is to type some simple statement that doesn't
involve any deployment or other I/O
and see how it works. In 80% of cases the same could be done in yaql CLI
tool. That's why I don't expect it to be that much of a productivity boost.
IMO debugger will do much better. And we could have an expression
evaluation functionality within debugger.

Btw, most of the steps you mentioned can be solved by an application stub
generator and configuration setting that will make murano take packages
from the local folder

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

<slagun at mirantis.com>

On Tue, Aug 16, 2016 at 7:31 AM, Alexander Tivelkov <ativelkov at mirantis.com>
wrote:

> Hi folks,
>
> The developer's productivity and ease of use is critical for the language
> adoption, and I believe we have issues with these in MuranoPL. The things
> are slowly getting better (thanks to the guys who are bulding th MuranoPL
> syntax checker [1] which will be a very useful tool), but that's not
> enough: we need more tools to simplify dev's life.
>
> Let me provide a quick example: what does it take to run a "Hello World"
> in MuranoPL?
> To create such an introductory MuranoPL program the developer has to:
> 1) Install Murano with the rest of openstack (i.e. spin up devstack with
> Murano and Glare plugins)
> 2) Write the actual HelloWorld "program" (mind the absence of simple
> "print" function and the non-so-obvious need to extend
> io.murano.Application class for the example to be runnable as murano's
> entry point)
> 3) Write the UI.yaml file to provide the input object graph (even if there
> is no user-supplied paramters - we still have to have this file)
> 4) Write a manifest.yaml
> 5) zip the program, the ui and the manifest into a package
> 6) Upload the package to Glare
> 7) Create an environment in Murano dashboard
> 8) Add the demo app to the environment
> 9) Deploy the environment
>
> I hope I din't miss any step. Even excluding the time to spin up devstack
> (and the high probability that a newcomer will not do that properly from
> the first attempt) this is going to take at least 30 minutes. Even when the
> environment is set up, the whole "make code changes - recreate the package
> - reupload the package - recreate the environment - redepoy" cycle is
> cumbersome.
>
> What do we need is a simple and easy way to run MuranoPL code without the
> need to set up all the server-sides components, generate object model and
> interact with all the production-grade machinery murano has under the hood.
> To do something like:
>
>    $ cat "- print('Hello, World')" > ./hello.yaml
>    $ murano-pl ./hello.yaml
>
> Ideally there should be an interactive REPL-like shell, with smart
> indentation and code completion similar to the Python's (we have one for
> yaql, and so we should for MuranoPL).
>
> That is not a very hard thing to do, and it will simplify the developers'
> onboarding dramatically.
>
> So, I propose to start with a simple thing: to separate the MuranoPL
> interpreter (mostly the code located in murano.dsl package, plus some other
> stuff) from the rest of Murano. Put it into a standalone reporitory, so it
> may be packaged and distributed independently. The developers will just
> need to 'pip install murano-pl' to have the local interpreter without all
> the dependencies on murano api, engine, database etc. This new package may
> include the murano-pl test-runner (this tool is currently part of the main
> murano repo and is hard to use since it requires to have a valid config
> file which is not a proper option for a cli tool). Then we may include some
> other devloper-side tools, such as a murano-pl debugger (when we finally
> have one: this is a separate topic).
> Finally, we will need to remove the core library (murano.engine.system)
> package from the main murano repo and also make it a standalone
> repo/package with its own lifecycle (it would be very helpfull if we could
> release/update the core library more frequently). So the main murano repo
> (and appropriate package) will contain only the server-side murano
> components: the REST API, the engine, DB api, model and migrations etc.
>
> When this is done we may begin adding other developer's productivity
> tools: starting with debugger and then to various kinds of IDE
> integrations.
>
> Thoughts, opinions?
>
>
> [1] https://github.com/openstack/murano-specs/blob/master/
> specs/newton/approved/validation-tool.rst
> --
> Regards,
> Alexander Tivelkov
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160824/54566916/attachment.html>