Zane Bitter zbit...@redhat.com wrote on 11/15/2013 05:59:06 PM:
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
On 20/11/13 20:09, Mike Spreitzer wrote:
Zane Bitter zbit...@redhat.com wrote on 11/15/2013 05:59:06 PM:
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,
Excerpts from Mike Spreitzer's message of 2013-11-20 11:09:34 -0800:
OTOH, the more we restrict what can be done, the less useful this really
is.
I would be more specific and say it as ...the less divergent behavior
is actually possible.
It will be quite a bit more useful if it is boring and
Hi,
On 11/15/13 9:17 PM, Georgy Okrokvertskhov
gokrokvertsk...@mirantis.com wrote:
You are right. At the same time heat feature should not enforce some
specific deployment requirements to other openstack components
especially taking into account different security considerations. I am
Excerpts from Zane Bitter's message of 2013-11-15 12:41:53 -0800:
Good news, everyone! I have created the missing whiteboard diagram that
we all needed at the design summit:
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram
I've documented 5
On 19/11/13 19:03, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2013-11-15 12:41:53 -0800:
Good news, everyone! I have created the missing whiteboard diagram that
we all needed at the design summit:
On 16/11/13 00:07, Georgy Okrokvertskhov wrote:
Hi,
With slight modifications of (2) one can benefit of availability:
1. There should not be a master node. Each heat engine should be able to
act as a master if someone asks it to deploy a template. Current master
engine will be responsible to
...@ntti3.com wrote on 14.11.2013 15:58:39:
From: Bartosz Górski bartosz.gor...@ntti3.com
To: openstack-dev@lists.openstack.org,
Date: 14.11.2013 16:05
Subject: [openstack-dev] [Heat] Continue discussing multi-region
orchestration
Hi all,
At summit in Hong Kong we had a design session where we
.com wrote on 14.11.2013 15:58:39:
From: Bartosz Górski bartosz.gor...@ntti3.com
To: openstack-dev@lists.openstack.org,
Date: 14.11.2013 16:05
Subject: [openstack-dev] [Heat] Continue discussing multi-region
orchestration
Hi all,
At summit in Hong Kong we had a design session where we
On 15/11/13 18:35, Georgy Okrokvertskhov wrote:
First of all, I believe this approach assumes that heat engine can reach
API endpoints which are located in different region. I am not sure if it
is a default deployment approach when someone is exposing OpenStack
services endpoints to the outside
become an orchestrator
itself then?
Regards,
Thomas
Bartosz Górski bartosz.gor...@ntti3.com wrote on 14.11.2013 15:58:39:
From: Bartosz Górski bartosz.gor...@ntti3.com
To: openstack-dev@lists.openstack.org,
Date: 14.11.2013 16:05
Subject: [openstack-dev] [Heat] Continue discussing multi
On Fri, Nov 15, 2013 at 10:44 AM, Stephen Gran stephen.g...@theguardian.com
wrote:
Surely those are local deployment policy decisions that shouldn't affect
the development of capabilities in heat itself, right? If a deployer does
not want one heat deployment to be able to reach some
Good news, everyone! I have created the missing whiteboard diagram that
we all needed at the design summit:
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram
I've documented 5 possibilities. (1) is the current implementation,
which we agree we
On 11/15/2013 01:41 PM, Zane Bitter wrote:
Good news, everyone! I have created the missing whiteboard diagram
that we all needed at the design summit:
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram
I've documented 5 possibilities. (1) is
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
-
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
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
Hi,
With slight modifications of (2) one can benefit of availability:
1. There should not be a master node. Each heat engine should be able to
act as a master if someone asks it to deploy a template. Current master
engine will be responsible to contact other engines and pass them the same
Hi all,
At summit in Hong Kong we had a design session where we discussed adding
multi-region orchestration support to Heat. During the session we had
really heated discussion and spent most of the time on explaining the
problem. I think it was really good starting point and right now more
Górski bartosz.gor...@ntti3.com
To: openstack-dev@lists.openstack.org,
Date: 14.11.2013 16:05
Subject: [openstack-dev] [Heat] Continue discussing multi-region
orchestration
Hi all,
At summit in Hong Kong we had a design session where we discussed adding
multi-region orchestration support
20 matches
Mail list logo
