[Openstack-operators] Sharing resources across OpenStack instances

Richard Raseley richard at raseley.com
Thu Apr 23 21:34:01 UTC 2015

Fox, Kevin M wrote:
> I'm thinking more like this use case: I'm a cloud user, I want a new
> Trac site. or an Elastic Search cluster. Or a Jenkins system for my
> project. Why do I have to take a lot of time to deploy these things
> myself? Ideally, one person, or a small group of folks provide
> generic templates a common deployment of a given software that can
> easily be discovered/launched by end users of any cloud. Docker is
> starting to do this with the Docker Hub. Docker's too low level to do
> it really nicely though. Say for an ElasticSearch cluster, you want
> it scalable, with between M and N instances, with a load balancer and
> a private network. Heat can do that... Murano is starting to enable
> that ability, but requires the cloud admin to preload up all the bits
> into it. That doesn't scale well though.
> I guess the how of how that works is up for grabs. Murano might not
> be the right place for it.
> What other use cases for transferring resources between clouds can
> you think of?

I have thought of the following:

* Swift - Users want to transfer objects or containers.

* Glance - Users want to transfer images and their associated metadata.

* Cinder - Users want to transfer block devices, though this could be 
plausibly covered by Glance (vols -> images -> vols).

* Heat - Users want to transfer stack templates. I know we don't have 
the ability to natively store these artifacts at this time (in the same 
way Glance stores images).

* Manilla - Users want to transfer files or folder hierarchies.

> Perhaps if the app store like functionality was simply http based,
> the existing glance fetch image from http mechanism would already
> work.

Seems reasonable, as long as you could give it a feed or endpoint to 
poll on a regular interval.

> Another option would be for it to work similarly to yum/apt. You have
> a set of repo's. You can search though the enabled repo's and install
> stuff. Perhaps it has a yum-cron like "update the images that are
> 'installed' daily" like feature...

I think you're touching on a lot of important (and really good) ideas 
here, it seems like there are various plausible ways one could go about

You've also touched on something that I've never really understood, 
which is why does Murano exist at all?

This is obviously off-topic in the context of this particular 
discussion, but it seems to me like we already have something that can 
store objects and metadata (Glance) and something that handles 
application deployment and orchestration (Heat). It seems that the 
functionality of Murano should've naturally fell into these two projects 
with (a) Glance becoming a more general 'artifact' storage and metadata 
service and (b) Heat gaining the 'catalog' capability of Murano. In this 
way, specific applications would be represented by their own Heat 
templates, those templates could then be combined in an ad hoc way to 
build environments (which I believe is the terminology used in Murano) 
and then the the resulting composition would be orchestrated by Heat.

Perhaps I am missing something fundamental which Murano does...

More information about the OpenStack-operators mailing list