<div dir="ltr">Hi Thierry,<br><br><br>Let me clarify the situation with existing programs and projects overlap. First of all, I would like to separate questions about what program Murano as a project can fit and about any overlap with existing projects in the official programs.<br>
<br><br>We position Application Catalog as a project that provides functionality for application publishing, distribution and management. What we were suggesting is that Murano as a project might fit in a Catalog program which technically does not exist yet, but this could possibly be one of the ways how current Image program might evolve.<br>
<br><br>On the project level, I don’t see any overlap with existing Glance project functionality. The Murano team is actively working with the Glance team to define a roadmap towards more generic metadata repository functionality for storing metadata not only images but other artifacts like application packages, Heat templates etc. Once this roadmap is realized, Murano would use a Glance repository for storing metadata.<br>
<br><br>Let me also explain why we listed Orchestration program as a possible place for Murano. The Orchestration mission states that the goal “is to create a human- and machine-accessible service for managing the entire lifecycle of infrastructure and applications within OpenStack clouds”. An application catalog provides self-service capabilities for a cloud user to manage applications on top of the cloud. In this form, the mission of the Orchestration program can be applied to the Murano project.<br>
<br><br>The fact that Murano fits the Orchestration mission does not mean that there is an overlap with existing projects in this program. Murano uses Heat to perform actual deployment. In this sense Murano does not deploy most things directly. Murano uses application definition to generate a Heat template from Heat template snippets. A good analogy here is the TripleO project which combines Heat templates based on desired OpenStack configuration and uses Heat to perform actual work.<br>
<br><br>The key functionality in Murano is an application package definition. An application package consists of a UI definition, metadata to control its appearance in the Catalog, requirements which help Catalog to find a required or dependent  applications, rules to control Heat template definitions from snippets and scripts which are part of application packages too. An essential requirement is to keep Murano project solid as it covers all aspects of working with application starting from UI appearance and ending with controlling a heat template-based deployment.<br>
<br><br>I also wouldn’t completely disregard an option to create a new program combining few projects to cover aspects of application management.<br><br><br>As you can see this is complicated topic with a number of possible solutions. What Murano team is seeking to achieve is to get feedback of community and TC on the most appropriate way to structure the governance model for the project.<br>
<br>Thanks<div>Georgy<br><br><br>On Mon, Feb 24, 2014 at 2:24 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>><br>> Mark Washenberger wrote:<br>> > Prior to this email, I was imagining that we would expand the Images<br>
> > program to go beyond storing just block device images, and into more<br>> > structured items like whole Nova instance templates, Heat templates, and<br>> > Murano packages. In this scheme, Glance would know everything there is<br>
> > to know about a resource--its type, format, location, size, and<br>> > relationships to other resources--but it would not know or offer any<br>> > links for how a resource is to be used.<br>><br>> I'm a bit uncomfortable as well. Part of our role at the Technical<br>
> Committee is to make sure additions do not overlap in scope and make<br>> sense as a whole.<br>><br>> Murano seems to cover two functions. The first one is publishing,<br>> cataloging and discovering software stacks. The second one is to deploy<br>
> those software stacks and potentially manage their lifecycle.<br>><br>> In the OpenStack "integrated" release we already have Glance as a<br>> publication/catalog/discovery component and Heat as the workload<br>
> orchestration end. Georgy clearly identified those two facets, since the<br>> incubation request lists those two programs as potential homes for Murano.<br>><br>> The problem is, Orchestration doesn't care about the Catalog part of<br>
> Murano, and Glance doesn't care about the Orchestration part of Murano.<br>> Murano spans the scope of two established programs. It's not different<br>> enough to really warrant its own program, and it's too monolithic to fit<br>
> in our current landscape.<br>><br>> I see two ways out: Murano can continue to live as a separate<br>> application that lives on top of OpenStack and consumes various<br>> OpenStack components. Or its functionality can be split and subsumed by<br>
> Glance and Heat, with Murano developers pushing it there. There seems to<br>> be interest in both those programs to add features that Murano covers.<br>> The question is, could we replicate Murano's featureset completely in<br>
> those existing components ? Or is there anything Murano-unique that<br>> wouldn't fit in existing projects ?<br>><br>> --<br>> Thierry Carrez (ttx)<br>><br>> _______________________________________________<br>
> OpenStack-dev mailing list<br>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br><br><br><br>--<br>Georgy Okrokvertskhov<br>Architect,<br>OpenStack Platform Products,<br>Mirantis<br><a href="http://www.mirantis.com">http://www.mirantis.com</a><br>Tel. +1 650 963 9828<br>Mob. +1 650 996 3284</div></div>