On Mon, 2014-02-24 at 11:24 +0100, Thierry Carrez 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.
There is a third component: the UI pieces. This naturally would belong in the UX program. > 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 ? Outside of its innovative UX form-construction component, the biggest thing that makes Murano unique (IMO) is its use of flow control constructs in its DSL. If I'm not mistaken, the Heat community has made it clear that they do not intend to introduce flow control constructs into HOT, and so there would be this piece that would need to live outside of Heat, but still in the Orchestration program. So, I believe that there is still a compelling reason for Murano to exist as a separate project within the Orchestration program, with a mission to provide a higher level DSL for deployment of complex application topologies that includes flow control contructs. And then someone will ask "well, isn't that partly what Solum is designed for?". And we're back to a similar discussion ;) Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
