Man I'd love for some mesos integration with openstack... On Thu, Apr 23, 2015 at 3:31 PM, Fox, Kevin M <kevin....@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 [rich...@raseley.com] > Sent: Thursday, April 23, 2015 12:01 PM > To: Fox, Kevin M > Cc: openstack-operators@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators