[openstack-dev] [Heat] Multi region support for Heat

Steve Baker sbaker at redhat.com
Tue Jul 23 04:43:05 UTC 2013


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.

I've been thinking about this recently and can see a more generic case
than multi-region.

Currently a stack is launched into a single cloud, into a context which
includes:
- keystone endpoint
- tenant/project
- user credentials

If this context was represented as a template resource (and also
specified a region), then other resources could specify which context to
provision within.

This is more generic than multi-region because some contexts can have
completely different keystone endpoints (multi-cloud), or can have the
same endpoint & region and only differ in the credentials or tenant.

This could also fulfill requirements such as these
https://lists.launchpad.net/openstack/msg25031.html

So I would modify your blueprint template examples in the following way:
- assume the new HOT template work will provide something that will make
those Mappings sections unnecessary
- Create a new resource OS::Cloud::Context with properties for keystone
endpoint, tenant, credentials and region.
- Allow all other resources to optionally specify a context (instead of
RegionName)
- in the implementation, give the resource the appropriate instance of
OpenStackClients which matches the requested context

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130723/20d80158/attachment.html>


More information about the OpenStack-dev mailing list