On Tue, Mar 25, 2014 at 2:27 PM, Thomas Herve <thomas.he...@enovance.com>wrote:
> > >> 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. > > 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 out and let it execute any JavaScript it wants unless it it JavaScript and not browser plugin or desktop application. > > -- > Thomas > > _______________________________________________ > OpenStack-dev mailing list > 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 sla...@mirantis.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
