Open Stack

Hi Thierry,


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.


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.


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.


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.


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.


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.


I also wouldn't completely disregard an option to create a new program
combining few projects to cover aspects of application management.


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.

Thanks
Georgy


On Mon, Feb 24, 2014 at 2:24 AM, Thierry Carrez <thierry at openstack.org>
wrote:
>
> Mark Washenberger wrote:
> > Prior to this email, I was imagining that we would expand the Images
> > program to go beyond storing just block device images, and into more
> > structured items like whole Nova instance templates, Heat templates, and
> > Murano packages. In this scheme, Glance would know everything there is
> > to know about a resource--its type, format, location, size, and
> > relationships to other resources--but it would not know or offer any
> > links for how a resource is to be used.
>
> I'm a bit uncomfortable as well. Part of our role at the Technical
> Committee is to make sure additions do not overlap in scope and make
> sense as a whole.
>
> Murano seems to cover two functions. The first one is publishing,
> cataloging and discovering software stacks. The second one is to deploy
> those software stacks and potentially manage their lifecycle.
>
> In the OpenStack "integrated" release we already have Glance as a
> publication/catalog/discovery component and Heat as the workload
> orchestration end. Georgy clearly identified those two facets, since the
> incubation request lists those two programs as potential homes for Murano.
>
> The problem is, Orchestration doesn't care about the Catalog part of
> Murano, and Glance doesn't care about the Orchestration part of Murano.
> Murano spans the scope of two established programs. It's not different
> enough to really warrant its own program, and it's too monolithic to fit
> in our current landscape.
>
> I see two ways out: Murano can continue to live as a separate
> application that lives on top of OpenStack and consumes various
> OpenStack components. Or its functionality can be split and subsumed by
> Glance and Heat, with Murano developers pushing it there. There seems to
> be interest in both those programs to add features that Murano covers.
> The question is, could we replicate Murano's featureset completely in
> those existing components ? Or is there anything Murano-unique that
> wouldn't fit in existing projects ?
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140224/200893dd/attachment.html>