Open Stack

> -----Original Message-----
> From: Richard Raseley [mailto:richard at raseley.com]
> Sent: Thursday, April 23, 2015 2:34 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:
> > 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.

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

Also makes sense.

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

Yeah, there are a lot of ways to do this one. There's also snapshots and backups too. :/
I've often wanted to download a cinder volume as a qcow2 file.

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

I haven’t tried it, but https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/glance-artifacts-it-and-39-s-not-just-for-images-anymore claims heat artifacts are working in juno. So maybe specifically heat resource transfer isn't needed if glance has it covered.

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

Hmm.... So is rsync out of the question, or are you more interested in scheduling/managing transfers via the cloud?

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

This was brought up precisely when Murano tried to incubate. And its one of the reasons a lot of functionality got pushed over into Glance I think. I'm not really sure where Murano fits long term in the picture either, but I do know for sure that the app catalog system needs some kind of UI, and if all the rest of the Murano bits get pushed into the other OpenStack projects, I'm guessing that will still be needed. Whether the result is still called Murano, or it ends up just being folded into Horizon's project, that may not matter. The important thing is there's an app catalog.

Thanks,
Kevin