<div dir="ltr">I put myself in Boris' camp on this one. This can open up the opportunity for negative user-experience, purely based on where I authenticate and which token I happen to authenticate with. A token would no longer be something I can assume to be properly validated against any node in my deployment. Now, when I receive a 401 Unauthorized, is it because the token is actually invalid, did I use the wrong endpoint, or did I use a token with the wrong scope for the endpoint I wanted to interact with?</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 5, 2016 at 2:43 PM, Ian Cordasco <span dir="ltr"><<a href="mailto:sigmavirus24@gmail.com" target="_blank">sigmavirus24@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----Original Message-----<br>
From: Andrey Grebennikov <<a href="mailto:agrebennikov@mirantis.com">agrebennikov@mirantis.com</a>><br>
Reply: OpenStack Development Mailing List (not for usage questions)<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Date: December 5, 2016 at 12:22:09<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject:  [openstack-dev] [keystone] Custom ProjectID upon creation<br>
<br>
> Hi keystoners,<br>
<br>
I'm not a keystoner, but I hope youu don't mind my replying.<br>
<span class=""><br>
> I'd like to open the discussion about the little feature which I'm trying<br>
> to push forward for a while but I need some feedbacks/opinions/concerns<br>
> regarding this.<br>
> Here is the review I'm talking about <a href="https://review" rel="noreferrer" target="_blank">https://review</a>.<br>
> <a href="http://openstack.org/#/c/403866/" rel="noreferrer" target="_blank">openstack.org/#/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 distributed<br>
> cloud. With global authentication (LDAP backed) and same roles names this<br>
> is only one missing piece which prevents the user to switch between regions<br>
> even withing single Horizon session.<br>
<br>
</span>So this just doesn't sound right to me. You say above that there are<br>
independent Keystone deployments in each region. What token type are<br>
you using that each region could validate a token (assuming project<br>
IDs that are identical across regions) that would do this for<br>
"independent Keystone" deployments?<br>
<br>
Specifically, let's presume you use Keystone's new default of fernet<br>
tokens and you have independently deployed Keystone in each region.<br>
Without synchronizing the keys Keystone uses to generate and validate<br>
fernet tokens, I can't imagine how one token would work across all<br>
regions. This sounds like a lofty goal.<br>
<br>
Further, if Keystone is backed by LDAP, why are there projects being<br>
created in the Keystone database at all? I thought using LDAP as a<br>
backend would avoid that necessity. (Again, I'm not a keystone<br>
developer ;))<br>
<span class=""><br>
> 2. Automated tools responsible for statistics collection may access all<br>
> regions using one token (real customer's usecase)<br>
<br>
</span>Why can't the automated tools be updated to talk to each Keystone and<br>
get a token while talking to that region?<br>
<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>
</span>So, Glance replication doesn't even guarantee identical image IDs<br>
across regions. If Glance's replication isn't working because the<br>
owner project is being synchronized directly, that sounds like a bug<br>
in Glance, not Keystone.<br>
<span class=""><br>
> What I hear all time - "you have to replicate your database" which from the<br>
> devops/deployment/operations perspective is totally wrong approach.<br>
<br>
</span>DevOps is a movement [1]. Replicating the database is not pleasant,<br>
no, but it is your better option. I'll repeat, though, why is your<br>
LDAP backed Keystone so reliant on Keystone's DB?<br>
<span class=""><br>
> If it is possible to avoid Galera replication over geographically<br>
> distributed regions - then API calls should be used. Moreover, in case of 2<br>
> DCs there will be an issue to decide which region has to take over when<br>
> they are isolated from each other.<br>
><br>
> There is a long conversation in the comments of the review, mainly with<br>
> concerns from cores (purely developer's opinions).<br>
<br>
</span>You say that as if developer opinions (the folks who have to<br>
understand and maintain your desired approach) is invalid or<br>
worthless. That's not the case.<br>
<span class=""><br>
> Please help me to bring it to life ;)<br>
<br>
</span>Please give us more detail and convince us to help you. :)<br>
<br>
[1]: <a href="https://theagileadmin.com/what-is-devops/" rel="noreferrer" target="_blank">https://theagileadmin.com/<wbr>what-is-devops/</a><br>
<br>
--<br>
Ian Cordasco<br>
<div class="HOEnZb"><div class="h5"><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></div>