[Openstack-operators] Sharing resources across OpenStack instances

matt matt at nycresistor.com
Thu Apr 23 19:55:42 UTC 2015


Man I'd love for some mesos integration with openstack...

On Thu, Apr 23, 2015 at 3:31 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> 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?
>
> 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
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150423/800a6746/attachment.html>


More information about the OpenStack-operators mailing list