Keith, I believe it is the same place Marketplace has in AWS or OpenShift Application Gallery to Red Hat OpenShift. The idea was of having free/open app catalog that cloud admins can fill with application metadata describing those apps and then end users construct environments from those applications in user friendly UI.
It is not ready recipes like Heat templates are that you only have to fill several parameters and the whole stack created for you but a constructor (think LEGO) for applications. Lets take a normal non-tech user (who cannot program/write JSON/YAML/whatever templates etc.) who wants to install Drupal on his OpenStack account. With Heat it would require finding HOT template for Drupal, answer several questions and click one button in Thermal. Then new Heat stack would be created with typically one VM for Drupal and another for MySQL. With Murano UI user finds Drupal in App Catalog and puts it onto environment. Now if he clicks "deploy" at this point the result would be the same as in Heat. But he also can edit what was generated. For example UI shows that Drupal requires a database that can be MySQL or PostgreSQL. Instead of vanilla MySQL user can go to App Catalog and peak Galera MySQL or PostgreSQL or something else that is compatible with those 2 DBMS. Or he can reuse database server that already exist in his environment. Drupal is hosted on web server so again user can replace Apache with Ngnix or host Drupal on some existing web server. The same goes for VM instances - user may choose to have both database and Drupal on the same VM. Now if you take all the components involved with even simple app like Drupal (Drupal, web server, PHP module for web server, database, VMs, operating systems, instance flavors) there are hundreds of combinations that can be constructed. With the Heat it would require hundreds of HOT templates (even if we forget that Heat cannot refer to resources located in another stack). And if user later decides to add load balancer to his environment to balance Drupal instances he is in trouble because load balancer brings another set of combinations (different LB implementations, underlying operating system, flavor) and things become unmanageable. So Heat is good for DevOps that can write HOT templates for exact task with all the control possible. And Murano is for the rest of us. It is something cloud providers can expose to users that do not know JSON, shell, puppet etc but want to install complex applications and still have control on it. On Tue, Feb 18, 2014 at 4:41 AM, Keith Bray <[email protected]>wrote: > > Can someone elaborate further on the things that Murano is intended to > solve within the OpenStack ecosystem? My observation has been that Murano > has changed from a Windows focused Deployment Service to a Metadata > Application Catalog Workflow thing (I fully admit this may be an invalid > observation). It's unclear to me what OpenStack pain/use-cases is to be > solved by "complex object composition, description of data types, > contracts..." > > Your thoughts would be much appreciated. > > Thanks, > -Keith > > From: Renat Akhmerov <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Date: Monday, February 17, 2014 1:33 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Subject: Re: [openstack-dev] [Murano] Need a new DSL for Murano > > Clint, > > We're collaborating with Murano. We may need to do it in a way that > others could see it though. There are several things here: > > - Murano doesn't really have a "workflow engine" similar to Mistral's. > People get confused with that but it's just a legacy terminology, I think > Murano folks were going to rename this component to be more precise about > it. > - Mistral DSL doesn't seem to be a good option for solving tasks that > Murano is intended to solve. Specifically I mean things like complex object > composition, description of data types, contracts and so on. Like Alex and > Stan mentioned Murano DSL tends to grow into a full programming language > . > - Most likely Mistral will be used in Murano for implementation, at > least we see where it would be valuable. But Mistral is not so matured yet, > we need to keep working hard and be patient :) > > > Anyway, we keep thinking on how to make both languages look similar or > at least the possibility to use them seamlessly, if needed (call Mistral > workflows from Murano DSL or vice versa). > > Renat Akhmerov > @ Mirantis Inc. > > On 16 Feb 2014, at 05:48, Clint Byrum <[email protected]> wrote: > > Excerpts from Alexander Tivelkov's message of 2014-02-14 18:17:10 -0800: > > Hi folks, > > Murano matures, and we are getting more and more feedback from our early > adopters. The overall reception is very positive, but at the same time > there are some complaints as well. By now the most significant complaint is > is hard to write workflows for application deployment and maintenance. > > Current version of workflow definition markup really have some design > drawbacks which limit its potential adoption. They are caused by the fact > that it was never intended for use for Application Catalog use-cases. > > > Just curious, is there any reason you're not collaborating on Mistral > for this rather than both having a workflow engine? > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > 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 [email protected]
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
