<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 07/23/2013 10:46 AM, Angus Salkeld
wrote:<br>
</div>
<blockquote cite="mid:20130722224645.GA25035@redhat.com" type="cite">On
22/07/13 16:52 +0200, Bartosz Górski wrote:
<br>
<blockquote type="cite">Hi folks,
<br>
<br>
I would like to start a discussion about the blueprint I raised
about multi region support.
<br>
I would like to get feedback from you. If something is not clear
or you have questions do not hesitate to ask.
<br>
Please let me know what you think.
<br>
<br>
Blueprint:
<a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/heat/+spec/multi-region-support">https://blueprints.launchpad.net/heat/+spec/multi-region-support</a>
<br>
<br>
Wikipage:
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat">https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat</a><br>
<br>
</blockquote>
<br>
What immediatley looks odd to me is you have a MultiCloud Heat
talking
<br>
to other Heat's in each region. This seems like unneccessary
complexity to me.
<br>
I would have expected one Heat to do this job.
<br>
</blockquote>
<br>
It should be possible to achieve this with a single Heat
installation - that would make the architecture much simpler.<br>
<br>
I've been thinking about this recently and can see a more generic
case than multi-region.<br>
<br>
Currently a stack is launched into a single cloud, into a context
which includes:<br>
- keystone endpoint<br>
- tenant/project<br>
- user credentials<br>
<br>
If this context was represented as a template resource (and also
specified a region), then other resources could specify which
context to provision within.<br>
<br>
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.<br>
<br>
This could also fulfill requirements such as these
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="https://lists.launchpad.net/openstack/msg25031.html">https://lists.launchpad.net/openstack/msg25031.html</a><br>
<br>
So I would modify your blueprint template examples in the following
way:<br>
- assume the new HOT template work will provide something that will
make those Mappings sections unnecessary<br>
- Create a new resource OS::Cloud::Context with properties for
keystone endpoint, tenant, credentials and region.<br>
- Allow all other resources to optionally specify a context (instead
of RegionName)<br>
- in the implementation, give the resource the appropriate instance
of OpenStackClients which matches the requested context<br>
<br>
</body>
</html>