Open Stack

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" <zbitter at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>