Open Stack

Hi,

On 11/15/13 9:17 PM, "Georgy Okrokvertskhov" 
<gokrokvertskhov at 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 
> trying to rise a concern about possible security implications of that 
> particular approach of using exposed openstack APIs and bring security 
> requirements to the table for discussion. Probably this will help to 
> design better solution for heat to heat or DC to DC communication if 
> it exists. I hope that there is a room for discussion and it is 
> possible to influence on the final design and implementation. I really 
> want this feature to be flexible and useful for most of OpenStack 
> deployments rather then for some specific deployment case.s,
>
> Georgy Okrokvertskhov

Thank you for your security concerns. There is a room for discussion and 
possibility to influence the final design. This is the reason why I 
started this discussion.



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 the current implementation, 
> which we agree we want to get away from. I strongly favour (2) for the 
> reasons listed. I don't think (3) has many friends. (4) seems to be 
> popular despite the obvious availability problem and doubts that it is 
> even feasible. Finally, I can save us all some time by simply stating 
> that I will -2 on sight any attempt to implement (5).

Zane thank you for creating this diagram! I think it was really the 
missing piece. Without it people were confused. Right now I think they 
have better understanding of the possible solutions.


On 11/15/2013 01:41 PM, Zane Bitter wrote:

> On 11/15/13 2:58 PM, "Zane Bitter" <zbitter at redhat.com> wrote:
>
> 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_Heat/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.

Yes. You are right. The proof of concept version I implemented is the 
option (4). I agree with you about the problems you listed. I am not so 
concerned about the first one (region goes down) but the second one will 
be a bigger problem in production and I did not notice it before. Also 
exposing the API endpoint for all the services maybe not the best 
solution from the security perspective. We probably should go with 
option (2).

On 11/16/2013 09:20 AM, Zane Bitter wrote:
>
> On 15/11/13 22:17, Keith Bray wrote:
>> 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. 

It is the benefit but I think for now we can assume that we have Heat 
service deployed in each region.

The implementation differences between option (2) and (4) does not look 
like to be big.
May be we can add new option in heat configuration file to choose the 
way to create in different region in case when heat service is not 
available.

>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Best,
Bartosz