<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 1, 2017 at 3:46 PM, Andrey Grebennikov <span dir="ltr"><<a href="mailto:agrebennikov@mirantis.com" target="_blank">agrebennikov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We had a very similar conversation multiple times with Keystone cores (multi-site Keystone). </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Geo-rep Galera was suggested first and it was immediately declined (one of the reasons was the case of complete corruption of Keystone DB everywhere in case of accidental table corrupt in one site) by me as well as current customer.</div><div>Right after that I was told many times that federation is the only right way to go nowadays.</div></div></blockquote><div><br></div><div>After doing some digging, I found the original specification [0] and the meeting agenda [1] where we talked about the alternative.</div><div><br></div><div>If I recall correctly, I thought I remember the proposal (being able to specify project IDs at creation time) being driven by not wanting to replicate all of keystone's backends in multi-region deployments,but still wanting to validate tokens across regions. Today, if you have a region in Seattle and region in Sydney, a token obtained from a keystone in Seattle and validated in Sydney would require both regions to share identity, resource, and assignment backends (among others depending on what kind of token it is). The request in the specification would allow only the identity and role backends to be replicated but the project backend in each region wouldn't need to be synced or replicated. Instead, operators could create projects with matching IDs in each region in order for tokens generated from one to be validated in the other. Most folks involved in the meeting considered this behavior for project IDs to be a slippery-slope.</div><div><br></div><div>Federation was brought up because sharing identity information globally, but not project or role information globally sounded like federation (e.g. having all your user information in an IdP somewhere and setting up each region's keystone to federate to the IdP). The group seemed eager to expose gaps in the federation implementation that prevented that case and address those.</div><div><br></div><div>Hopefully that helps capture some of the context (feel free to fill in gaps if I missed any).</div><div><br></div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/323499/">https://review.openstack.org/#/c/323499/</a></div><div>[1] <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2016-05-31.log.html#t2016-05-31T18:05:05">http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2016-05-31.log.html#t2016-05-31T18:05:05</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Is this statement still valid?</div></div><div class="gmail_extra"><div><div class="gmail-h5"><br><div class="gmail_quote">On Thu, Jun 1, 2017 at 12:51 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 05/31/2017 11:06 PM, Mike Bayer wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'd also throw in, there's lots of versions of Galera with different bugfixes / improvements as we go along, not to mention configuration settings.... if Jay observes it working great on a distributed cluster and Clint observes it working terribly, it could be that these were not the same Galera versions being used.<br>
</blockquote>
<br></span>
Agreed. The version of Galera we were using IIRC was Percona XtraDB Cluster 5.6. And, remember that the wsrep_provider_options do make a big difference, especially in WAN-replicated setups.<br>
<br>
We also increased the tolerance settings for network disruption so that the cluster operated without hiccups over the WAN. I think the wsrep_provider_options setting was evs.inactive_timeout=PT30Sm evs.suspect_timeout=PT15S, and evs.join_retrans_period=PT1S.<br>
<br>
Also, regardless of settings, if your network sucks, none of these distributed databases are going to be fun to operate :)<br>
<br>
At AT&T, we jumped through a lot of hoops to ensure multiple levels of redundancy and high performance for the network links inside and between datacenters. It really makes a huge difference when your network rocks.<div class="gmail-m_-8294725086378697185HOEnZb"><div class="gmail-m_-8294725086378697185h5"><br>
<br>
Best,<br>
-jay<br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="gmail-HOEnZb"><font color="#888888">-- <br><div class="gmail-m_-8294725086378697185gmail_signature"><div dir="ltr"><div><div dir="ltr">Andrey Grebennikov<div>Principal Deployment Engineer</div><div>Mirantis Inc, Austin TX</div></div></div></div></div>
</font></span></div>
<br>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>