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 a
On 20/11/13 20:09, Mike Spreitzer wrote:
Zane Bitter 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'
Zane Bitter 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 have to work a
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:
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_M
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 documen
Hi,
On 11/15/13 9:17 PM, "Georgy Okrokvertskhov"
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
trying to rise a concern about
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 con
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
template
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 endpo
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
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
-
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 th
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 wa
On Fri, Nov 15, 2013 at 10:44 AM, Stephen Gran 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 endpoints, they'll
> set up a lo
r
>> itself then?
>>
>> Regards,
>> Thomas
>>
>> Bartosz Górski wrote on 14.11.2013 15:58:39:
>>> From: Bartosz Górski
>>> To: openstack-dev@lists.openstack.org,
>>> Date: 14.11.2013 16:05
>>> Subject: [openstack-dev] [Heat]
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 o
n
>> orchestration? In the discussions I heard people talking about the heat
>> client doing it. But wouldn't that duplicate functionality that is inside
>> the engine into the client, i.e. the client would become an orchestrator
>> itself then?
>>
>> Regar
wrote on 14.11.2013 15:58:39:
From: Bartosz Górski
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
: 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 to Heat. Du
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
pe
20 matches
Mail list logo
