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
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" <zbit...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Best,
Bartosz
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
