On 15/11/13 22:17, Keith Bray wrote:
The way I view 2 vs. 4 is that 2 is more complicated and you don't gain
any benefit of availability. If, in 2, your global heat endpoint is down,
you can't update the whole stack. You have to work around it by talking
to Heat (or the individual service endpoints) in the region that is still
alive.
Not really, you still have the templates for all of the nested stacks
that are in the remaining region(s). You can manipulate those directly
and not risk getting things out of sync when the Heat master comes back.
If you really want a global stack, you can recreate it in a different
region and adopt the remaining parts.
4 is much simpler in that only one Heat instance is involved. If Heat is
From a code perspective, there is no sense in which (4) is simpler.
down, you still have just as bad/good workaround, which is you talk to
service endpoints in the region that is still available. If you want to
That's considerably worse as a workaround IMO, because it gets reality
out of sync with your template.
use Heat in that region to do it, you can Adopt the resources into a Heat
stack in that region. I don't see how 2 is "Robust against failure of
whole region" because if the region on the left part of the picture in 2
goes down, you can't manage your global stack or any of the resources in
the left region that are part of that global stack. All you could manage
is a subset of resources by manipulating the substack in the right region,
but you can do this in 4 as well using Adopt. 4 is a simpler starting use
case and easier (IMO) for a user of the system to digest, and has the HUGE
advantage of being able to orchestrate deploying resources to multiple
regions without a service operator having to have Heat setup and installed
in EVERY region. This is particular important for a private cloud/heat
person trying to deploy to public cloud.. If doing so requires the public
cloud operator have Heat running, then you can't deploy there. If no Heat
in that region is required, then you can use your own instance of Heat to
deploy to any available openstack cloud. That is a HUGE benefit of 4.
Good point, I've added that to the Pro/Con in the wiki.
-Keith
On 11/15/13 2:58 PM, "Zane Bitter" <zbit...@redhat.com> wrote:
On 15/11/13 18:24, Bartosz Górski wrote:
Hi Thomas,
Each of the two engines will be able to create resources in both
regions.
We do not need to add anything in the heat client.
Right now when you want to create a new stack (using heat client or
directly API) you need to provide:
- stack name
- template
- parameters (if need)
- tenant
- username
- password
- region name (optional)
The last four (tenant, username, password and region_name) we will call
default context.
This context is used in Heat to configure all the openstack clients to
other service.
Username, password and tenant is used for authentication.
Region name is use to get appropriate API endpoint from keystone catalog
for other openstack service (like nova).
In case with one region you do not need to specify it because there is
only one endpoint for each service.
In multi-region case we have more than one and region name is used to
get correct one.
Each nested stack have its own set of openstack clients (nova client,
neutron client, ... etc.) inside the heat engine.
Right now for all of them the default context is used to configure
clients which will be used to create resources.
There is not option to change the default context for now. What I'm
trying to do it to add possibility to define different
context inside the template file. New context can be passed to nested
stack resource to create clients set with different
endpoints to call. Heat engine will get appropriate endpoints from
keystone catalog for specified region name.
So from heat engine point of view there is not big change in the
workflow. Heat will parse the template, create the
dependencies graph and start creating resources in the same way as
usual. When he will need to created nested
stack with different context he will just use different set of openstack
clients (ex. will call services in other region).
So to sum up each of the two heat engine will be able to create
resources in both regions if different context will
be specified. If only default context will be used heat will create all
resource in the same region where it is located.
So, to be clear, this is option (4) from the diagram I put together here:
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_H
eat/The_Missing_Diagram
It's got a couple of major problems:
* When a whole region goes down, you can lose access to the Heat
instance that was managing still-available resources. This makes it more
or less impossible to use Heat to manage a highly-available global
application.
* Instances have to communicate back to the Heat instance that owns them
(e.g. for WaitConditions), and it's not yet clear that this is feasible
in general.
There are also a number of other things I really don't like about this
solution (listed on the wiki page), though reasonable people may disagree.
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
