Clint, On Jul 23, 2013, at 10:03 AM, Clint Byrum <cl...@fewbar.com> wrote:
> Excerpts from Steve Baker's message of 2013-07-22 21:43:05 -0700: >> On 07/23/2013 10:46 AM, Angus Salkeld wrote: >>> On 22/07/13 16:52 +0200, Bartosz Górski wrote: >>>> Hi folks, >>>> >>>> I would like to start a discussion about the blueprint I raised about >>>> multi region support. >>>> I would like to get feedback from you. If something is not clear or >>>> you have questions do not hesitate to ask. >>>> Please let me know what you think. >>>> >>>> Blueprint: >>>> https://blueprints.launchpad.net/heat/+spec/multi-region-support >>>> >>>> Wikipage: >>>> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat >>>> >>> >>> What immediatley looks odd to me is you have a MultiCloud Heat talking >>> to other Heat's in each region. This seems like unneccessary >>> complexity to me. >>> I would have expected one Heat to do this job. >> >> It should be possible to achieve this with a single Heat installation - >> that would make the architecture much simpler. >> > > Agreed that it would be simpler and is definitely possible. > > However, consider that having a Heat in each region means Heat is more > resilient to failure. So focusing on a way to make multiple Heat's > collaborate, rather than on a way to make one Heat talk to two regions > may be a more productive exercise. I agree with Angus, Steve Baker, and Randall on this one. We should aim for simplicity where practical. Having Heat services interacting with other Heat services seems like a whole category of complexity that's difficult to justify. If it were implemented as Steve Baker described, and the local Heat service were unavailable, the client may still have the option to use a Heat service in another region and still successfully orchestrate. That seems to me like a failure mode that's easier for users to anticipate and plan for. Can you further explain your perspective? What sort of failures would you expect a network of coordinated Heat services to be more effective with? Is there any way this would be more simple or more elegant than other options? Adrian _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
