On May 14, 2013, at 3:59 PM, Russell Bryant <rbry...@redhat.com> wrote:
> On 05/13/2013 11:04 AM, Jay Pipes wrote: >> On 05/09/2013 04:29 PM, Chris Behrens wrote: >>> Yes, I think this makes a lot of sense. At some point we need to come back >>> around to bursting. One big thing we want to get to is being able to burst >>> from OS cloud to another OS cloud. I haven't spent a lot of time thinking >>> about it, but it feels like something that is done at a cell level. And >>> with these other 'complex systems' like vSphere and whatever that manage >>> their own pools of resources, you can think of them in the context of >>> bursting as well. It's just that, instead, we're bursting from OS to >>> vSphere, etc. >> >> But isn't a cell a privately-managed set of resources? In other words, >> one OS cloud doesn't know about another OS cloud's cells. All it knows >> about are the *published* segments/regions of an OS cloud -- in other >> words, the regions and availability zones. >> >> These concepts seem to be more akin to a Heat template and upper-level >> orchestration than to cell-to-cell scheduling. > > I think you're right, Jay. > > It seems that Chris' idea would be to allow using resources from another > region (or perhaps a different platform completely), without the client > side having to care about it since it will all be behind the same API > endpoint. > Wow, I guess I stopped checking this thread. :) Heat could make sense. But yeah, what Russell said is correct. I thought it would be desirable to have all instances behind the same nova-api because one potentially does not care at all where the instance actually lands…. So, I was thinking through normal cells scheduling, you could hit a child cell that is configured to solely burst into another cloud. That child cell could manage tracking state and report up state changes to the API, etc… I think we need to set some requirements and goals and only then will we be able to determine the best place for this. My thoughts were just based off of my own assumptions. - Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
