<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On 12/05/2016 09:20 PM, Andrey Grebennikov wrote:<br>
> Hi keystoners,<br>
> I'd like to open the discussion about the little feature which I'm<br>
> trying to push forward for a while but I need some<br>
> feedbacks/opinions/concerns regarding this.<br>
> Here is the review I'm talking<br>
> about <a href="https://review.openstack.org/#/c/403866/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/403866/</a><br>
> <<a href="https://review.openstack.org/#/c/403866/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/403866/</a>><br>
><br>
> What I'm trying to cover is multi-region deployment, which includes<br>
> geo-distributed cloud with independent Keystone in every region.<br>
><br>
> There is a number of use cases for the change:<br>
> 1. Allow users to re-use their tokens in all regions across the<br>
> distributed cloud. With global authentication (LDAP backed) and same<br>
> roles names this is only one missing piece which prevents the user to<br>
> switch between regions even withing single Horizon session.<br>
> 2. Automated tools responsible for statistics collection may access all<br>
> regions using one token (real customer's usecase)<br>
<br>
</span>What do you understand by "region"?<br></blockquote><div>I believe I explained what the "region" is in the beginning. In here it is actually a generic "keystone region" with all stuff, but Keystone is independent in it. Literally all Keystones in all "my" regions are aware about each other since they all have common catalog. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 3. Glance replication may happen because the images' parameter "owner"<br>
> (which is a project) should be consistent across the regions.<br>
><br>
> What I hear all time - "you have to replicate your database" which from<br>
> the devops/deployment/operations perspective is totally wrong approach.<br>
> If it is possible to avoid Galera replication over geographically<br>
> distributed regions - then API calls should be used. Moreover, in case<br>
> of 2 DCs there will be an issue to decide which region has to take over<br>
> when they are isolated from each other.<br>
<br>
</span>My comment in the review still stands. With the change we are getting<br>
ourselves into situation when some tokens *are* verifiable in 2<br>
regions (project-scoped with identical project ids in both regions),<br>
some *might be* verifiable in 2 regions (project-scoped with ids about<br>
which we can't tell anything), and some *are not* verifiable, because<br>
they are federation- or trust-scoped. A user (human or script) won't be<br>
able to tell what functionality the token brings without complex<br>
inspection.<br>
<br></blockquote><div>I commented it in the IRC and repeat over here - it is Always the responsibility of the administrator to realize how things work and implement it in the way he/she wants it. You don't need it - you don't set it. The IDs will be still generated.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Current design is there is single issuer of tokens and single<br>
consumer. With the patch there will be single issuer and multiple<br>
consumers. Which is basically SSO, but done without explicit<br>
design decision.<br>
<br></blockquote><div>Not true. SSO assumes Central point of authorization. Here it is highly distributed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is what i suggest:<br>
<br>
1. Stop thinking about 2 keystone installations with non-shared database<br>
as about "one single keystone". If there are 2 non-replicated databases,<br>
there are 2 separate keystones. 2 separate keystones have completely<br>
different sets of tokens. Do not try to share fernet keys between<br>
separate keystones.<br>
<br></blockquote><div>Even if you replicate the DB it is not going to work with no key replication. I repeat my statement once again - if the admin doesn't need it - leave the --id field blank, that's it. Nothing is broken.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Instead of implementing poor man's federation, use real federation.<br>
Create appropriate projects and create group-based assignments, one<br>
for each keystone instance. Use these group-based assignments for<br>
federated users.<br>
<span class="im HOEnZb"><br></span></blockquote><div>Does federation currently allow me to use remote groups? Does it allow me to replicate my projects? Does it allow me to work when there is no connectivity between keystones? Does it allow me to know whether user exists in the federated provider before I create shadow user? Does it delete assignments/shadow user records when the user is deleted from the remote provider? I can keep going forever. And yes, I don't mention CLI support of federation.</div><div>Feel free to add.</div><div><br></div><div>Thanks!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">
> There is a long conversation in the comments of the review, mainly with<br>
> concerns from cores (purely developer's opinions).<br>
><br>
> Please help me to bring it to life ;)<br>
><br>
> PS I'm so sorry, forgot to create a topic in the original message<br>
><br>
> --<br>
> Andrey Grebennikov<br>
> Principal Deployment Engineer<br>
> Mirantis Inc, Austin TX<br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> ______________________________<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>
<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_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>
</div></div>