Open Stack

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