[openstack-dev] [Murano][Heat] MuranoPL questions?
slagun at mirantis.com
Tue Mar 25 11:31:45 UTC 2014
On Tue, Mar 25, 2014 at 2:27 PM, Thomas Herve <thomas.herve at enovance.com>wrote:
> >> What I can say is that I'm not convinced. The only use-case for a DSL
> >> be if you have to upload user-written code, but what you mentioned is a
> >> interface, where the user doesn't use the DSL, and the cloud provider
> is the
> >> developer. There is no reason in this case to have a secure environment
> >> the code.
> > I didn't say that. There are at least 2 different roles application
> > developers/publishers and application users. Application developer is not
> > necessary cloud provider. The whole point of AppCatalog is to support
> > scenario when anyone can create and package some application and that
> > package can be uploaded by user alone. Think Apple AppStore or Google
> > Some cloud providers may configure ACLs so that user be allowed to
> > applications they decided while others may permit to upload applications
> > some configurable scope (e.g. apps that would be visible to all cloud
> > to particular tenant or be private to the user). We also think to have
> > of peer relations so that it would be possible to have application
> upload in
> > one catalog to become automatically available in all connected catalogs.
> > This is similar to how Linux software repos work - AppCatalog is repo,
> > package is what DEB/RPMs are to repo and DSL is what DEB/RPMs manifests
> > to packages. Just that is run on cloud and designed to handle complex
> > multi-node apps as well as trivial ones in which case this may be
> > to actual installation of DEB/RPM
> I'm glad that you bring packages up. This is a really good example of why
> you don't need a new programming language. Packages uses whatever
> technology they prefer to handle their scripting needs. They then have an
> declarative interface which hides the imperative parts behind.
The same is true for Murano. MuranoPL is not used to express what should be
deployed. In Murano there is object model that describes view of the word.
It serves for the same purpose as HOT in Heat but it is simpler because it
says just what need to be deployed but not how it should be accomplished as
this information is already contained in application definitions. There is
REST API to edit/submit Object Model which is again has nothing to do with
MuranoPL. UI dashboard talks to AppCatalog to see what applications/classes
are available and AppCatalog also knows what are the properties of those
classes. This is needed for UI so that it can ask user for appropriate
input. This is similar to how Horizon asks user to input parameters that
are declared in HOT template. But all the imperative stuff is hidden inside
Murano packages and is not used for anything outside Murano engine.
MuranoPL is not a replacement for scripting languages. You still use
bash/puppet/PowerShell/whatever you like for actual deployment. No MuranoPL
code is executed on VM side. So the analogy with RPMs manifests is valid.
> You trust OpenStack developers with their code, you trust package
> developers with their code, why not trust catalog developers?
They do trust catalog developers (hopefully). But catalog developers have
nothing to do with catalog contents. Anyone can create and upload
application to App Catalog the same way how anyone can upload his
application to Google Play. The fact that I trust Google doesn't mean that
I trust all applications in Google Play. The fact that I trust catalog
developers doesn't mean that I (as a cloud operator) is going to allow
execution of untrusted code in that catalog. Unless that code is sandboxed
by design. Similar to that I can navigate to any web site google points me
not browser plugin or desktop application.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
Stanislav (Stan) Lagun
35b/3, Vorontsovskaya St.
slagun at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev