<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Sep 2, 2015 at 8:30 AM Lowery, Mathew <<a href="mailto:mlowery@ebay.com">mlowery@ebay.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you Zane for the clarifications!<br>
<br>
I misunderstood #2 and that led to the other misunderstandings.<br>
<br>
Further questions:<br>
* Are nested stacks aware of their nested-ness? In other words, given any<br>
nested stack (colocated with parent stack or not), can I trace it back to<br>
the parent stack? (On a possibly related note, I see that adopting a stack<br></blockquote><div><br></div><div>Yes, there is a link (url) to the parent_stack in the links section of show stack.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
is an option to reassemble a new parent stack from its regional parts in<br>
the event that the old parent stack is lost.)<br>
* Has this design met the users' needs? In other words, are there any<br>
plans to make major modifications to this design?<br></blockquote><div><br></div><div>AFAIK we have had zero feedback from the multi region feature.</div><div>No more plans, but we would obviously love feedback and suggestions</div><div>on how to improve region support.</div><div><br></div><div>-Angus</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks!<br>
<br>
On 9/1/15, 1:47 PM, "Zane Bitter" <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>> wrote:<br>
<br>
>On 01/09/15 11:41, Lowery, Mathew wrote:<br>
>> This is a Trove question but including Heat as they seem to have solved<br>
>> this problem.<br>
>><br>
>> Summary: Today, it seems that Trove is not capable of creating a cluster<br>
>> spanning multiple regions. Is that the case and, if so, are there any<br>
>> plans to work on that? Also, are we aware of any precedent solutions<br>
>> (e.g. remote stacks in Heat) or even partially completed spec/code in<br>
>>Trove?<br>
>><br>
>> More details:<br>
>><br>
>> I found this nice diagram<br>
>><br>
>><<a href="https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for</a><br>
>>_Heat/The_Missing_Diagram> created<br>
>> for Heat. As far as I understand it,<br>
><br>
>Clarifications below...<br>
><br>
>> #1 is the absence of multi-region<br>
>> support (i.e. what we have today). #2 seems to be a 100% client-based<br>
>> solution. In other words, the Heat services never know about the other<br>
>> stacks.<br>
><br>
>I guess you could say that.<br>
><br>
>> In fact, there is nothing tying these stacks together at all.<br>
><br>
>I wouldn't go that far. The regional stacks still appear as resources in<br>
>their parent stack, so they're tied together by whatever inputs and<br>
>outputs are connected up in that stack.<br>
><br>
>> #3<br>
>> seems to show a "master" Heat server that understands "remote stacks"<br>
>> and simply converts those "remote stacks" into calls on regional Heats.<br>
>> I assume here the master stack record is stored by the master Heat.<br>
>> Because the "remote stacks" are full-fledged stacks, they can be managed<br>
>> by their regional Heats if availability of master or other regional<br>
>> Heats is lost.<br>
><br>
>Yeah.<br>
><br>
>> #4, the diagram doesn't seem to match the description<br>
>> (instead of one global Heat, it seems the diagram should show two<br>
>> regional Heats).<br>
><br>
>It does (they're the two orange boxes).<br>
><br>
>> In this one, a single arbitrary region becomes the<br>
>> owner of the stack and remote (low-level not stack) resources are<br>
>> created as needed. One problem is the manageability is lost if the Heat<br>
>> in the owning region is lost. Finally, #5. In #5, it's just #4 but with<br>
>> one and only one Heat.<br>
>><br>
>> It seems like Heat solved this <<a href="https://review.openstack.org/#/c/53313/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/53313/</a>><br>
>> using #3 (Master Orchestrator)<br>
><br>
>No, we implemented #2.<br>
><br>
>> but where there isn't necessarily a<br>
>> separate master Heat. Remote stacks can be created by any regional<br>
>>stack.<br>
><br>
>Yeah, that was the difference between #3 and #2 :)<br>
><br>
>cheers,<br>
>Zane.<br>
><br>
>> Trove questions:<br>
>><br>
>>  1. Having sub-clusters (aka remote clusters aka nested clusters) seems<br>
>>     to be useful (i.e. manageability isn't lost when a region is lost).<br>
>>     But then again, does it make sense to perform a cluster operation on<br>
>>     a sub-cluster?<br>
>>  2. You could forego sub-clusters and just create full-fledged remote<br>
>>     standalone Trove instances.<br>
>>  3. If you don't create full-fledged remote Trove instances (but instead<br>
>>     just call remote Nova), then you cannot do simple things like<br>
>>     getting logs from a node without going through the owning region's<br>
>>     Trove. This is an extra hop and a single point of failure.<br>
>>  4. Even with sub-clusters, the only record of them being related lives<br>
>>     only in the "owning" region. Then again, some ID tying them all<br>
>>     together could be passed to the remote regions.<br>
>>  5. Do we want to allow the piecing together of clusters (sort of like<br>
>>     Heat's "adopt")?<br>
>><br>
>> These are some questions floating around my head and I'm sure there are<br>
>> plenty more. Any thoughts on any of this?<br>
>><br>
>> Thanks,<br>
>> Mat<br>
>><br>
>><br>
>><br>
>>_________________________________________________________________________<br>
>>_<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>