<div dir="ltr"><div>The ability to specify IDs at project creation time was proposed as a specification last summer [0]. The common theme from the discussion in that thread was to use shadow mapping [1] to solve that problem.</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://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/shadow-mapping.html">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/shadow-mapping.html</a></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 5, 2016 at 12:47 PM, Steve Martinelli <span dir="ltr"><<a href="mailto:s.martinelli@gmail.com" target="_blank">s.martinelli@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"><div dir="ltr">I'm OK with the agreed approach in the patch, we restrict the ID being specified to 32 character UUID4 string. And it only works on project create, not update.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Mon, Dec 5, 2016 at 1:20 PM, Andrey Grebennikov <span dir="ltr"><<a href="mailto:agrebennikov@mirantis.com" target="_blank">agrebennikov@mirantis.com</a>></span> wrote:<br></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><div class="gmail-h5"><div dir="ltr"><span style="font-size:12.8px">Hi keystoners,</span><div style="font-size:12.8px">I'd like to open the discussion about the little feature which I'm trying to push forward for a while but I need some feedbacks/opinions/concerns regarding this.</div><div style="font-size:12.8px">Here is the review I'm talking about <a href="https://review.openstack.org/#/c/403866/" target="_blank">https://review.openstack<wbr>.org/#/c/403866/</a></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">What I'm trying to cover is multi-region deployment, which includes geo-distributed cloud with independent Keystone in every region.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">There is a number of use cases for the change:</div><div style="font-size:12.8px">1. Allow users to re-use their tokens in all regions across the distributed cloud. With global authentication (LDAP backed) and same roles names this is only one missing piece which prevents the user to switch between regions even withing single Horizon session.</div><div style="font-size:12.8px">2. Automated tools responsible for statistics collection may access all regions using one token (real customer's usecase)</div><div style="font-size:12.8px">3. Glance replication may happen because the images' parameter "owner" (which is a project) should be consistent across the regions.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">What I hear all time - "you have to replicate your database" which from the devops/deployment/operations perspective is totally wrong approach.</div><div style="font-size:12.8px">If it is possible to avoid Galera replication over geographically distributed regions - then API calls should be used. Moreover, in case of 2 DCs there will be an issue to decide which region has to take over when they are isolated from each other.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">There is a long conversation in the comments of the review, mainly with concerns from cores (purely developer's opinions).</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Please help me to bring it to life ;)</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">PS I'm so sorry, forgot to create a topic in the original message</div><span class="gmail-m_-6327203746091986145HOEnZb"><font color="#888888"><div><br></div>-- <br><div class="gmail-m_-6327203746091986145m_-7692313983776724960gmail_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></div></div>______________________________<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>
<br></blockquote></div><br></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>