Open Stack

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?

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

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...

Thanks,
Kevin
________________________________________
From: Richard Raseley [richard at raseley.com]
Sent: Thursday, April 23, 2015 12:01 PM
To: Fox, Kevin M
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] Sharing resources across OpenStack instances

Fox, Kevin M wrote:
> Some folks have been discussing an app store model. perhaps in
> Murano, but more global, that would allow images/template to be
> registered somewhere like on openstack.org and show up on all clouds
> that have the global repo enabled. Murano would be extended to fetch
> the images/templates to the local glance on the first launch of an
> app if its not already cached locally.
>
> Would that sort of thing fit better then trying to sync glances
> backing store between clouds?

My first take is that what you've outlined feels a little too ambitious
to me. I also have concerns (feature and scope creep) about whether or
not Murano (or any other project) should be in the business of managing
and auditing replication of data between various other (potentially
disparate) systems.

I think there is tremendous value at the core of the idea, which is
essentially the ability to easily (and granularly) share and consume
resources between clouds. To me that feels much more like something that
would be interested on a per-project basis (as has been done in Swift).

In the model I am imagining, the underlying components of the cloud
would be responsible for inter-cloud data replication.

In the specific case of Glance images, it could either take the form of
a pub / sub model at the Glance level (which would allow replication of
images between Glance systems utilizing different back-ends) or the form
of backend <-> backend replication (e.g. with Swift Container
Replication) and then Glance would simply have a process for discovering
new images which have appeared on the back-end.

Regards,

Richard Raseley

SysOps Engineer
Puppet Labs