[openstack-dev] [Murano][Heat] MuranoPL questions?

Thomas Herve thomas.herve at enovance.com
Tue Mar 25 10:27:11 UTC 2014


 
>> What I can say is that I'm not convinced. The only use-case for a DSL would
>> be if you have to upload user-written code, but what you mentioned is a Web
>> 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 for
>> 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 Play.
> Some cloud providers may configure ACLs so that user be allowed to consume
> applications they decided while others may permit to upload applications to
> some configurable scope (e.g. apps that would be visible to all cloud users,
> to particular tenant or be private to the user). We also think to have some
> 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, Murano
> package is what DEB/RPMs are to repo and DSL is what DEB/RPMs manifests are
> 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 narrowed
> 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.

You trust OpenStack developers with their code, you trust package developers with their code, why not trust catalog developers?

-- 
Thomas



More information about the OpenStack-dev mailing list