Open Stack

On 01/09/15 11:41, Lowery, Mathew wrote:
> This is a Trove question but including Heat as they seem to have solved
> this problem.
>
> Summary: Today, it seems that Trove is not capable of creating a cluster
> spanning multiple regions. Is that the case and, if so, are there any
> plans to work on that? Also, are we aware of any precedent solutions
> (e.g. remote stacks in Heat) or even partially completed spec/code in Trove?
>
> More details:
>
> I found this nice diagram
> <https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram> created
> for Heat. As far as I understand it,

Clarifications below...

> #1 is the absence of multi-region
> support (i.e. what we have today). #2 seems to be a 100% client-based
> solution. In other words, the Heat services never know about the other
> stacks.

I guess you could say that.

> In fact, there is nothing tying these stacks together at all.

I wouldn't go that far. The regional stacks still appear as resources in 
their parent stack, so they're tied together by whatever inputs and 
outputs are connected up in that stack.

> #3
> seems to show a "master" Heat server that understands "remote stacks"
> and simply converts those "remote stacks" into calls on regional Heats.
> I assume here the master stack record is stored by the master Heat.
> Because the "remote stacks" are full-fledged stacks, they can be managed
> by their regional Heats if availability of master or other regional
> Heats is lost.

Yeah.

> #4, the diagram doesn't seem to match the description
> (instead of one global Heat, it seems the diagram should show two
> regional Heats).

It does (they're the two orange boxes).

> In this one, a single arbitrary region becomes the
> owner of the stack and remote (low-level not stack) resources are
> created as needed. One problem is the manageability is lost if the Heat
> in the owning region is lost. Finally, #5. In #5, it's just #4 but with
> one and only one Heat.
>
> It seems like Heat solved this <https://review.openstack.org/#/c/53313/>
> using #3 (Master Orchestrator)

No, we implemented #2.

> but where there isn't necessarily a
> separate master Heat. Remote stacks can be created by any regional stack.

Yeah, that was the difference between #3 and #2 :)

cheers,
Zane.

> Trove questions:
>
>  1. Having sub-clusters (aka remote clusters aka nested clusters) seems
>     to be useful (i.e. manageability isn't lost when a region is lost).
>     But then again, does it make sense to perform a cluster operation on
>     a sub-cluster?
>  2. You could forego sub-clusters and just create full-fledged remote
>     standalone Trove instances.
>  3. If you don't create full-fledged remote Trove instances (but instead
>     just call remote Nova), then you cannot do simple things like
>     getting logs from a node without going through the owning region's
>     Trove. This is an extra hop and a single point of failure.
>  4. Even with sub-clusters, the only record of them being related lives
>     only in the "owning" region. Then again, some ID tying them all
>     together could be passed to the remote regions.
>  5. Do we want to allow the piecing together of clusters (sort of like
>     Heat's "adopt")?
>
> These are some questions floating around my head and I'm sure there are
> plenty more. Any thoughts on any of this?
>
> Thanks,
> Mat
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>