<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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Dec 5, 2016 at 2:31 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_-3503210754392994038h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">-----Original Message-----<br>
From: Andrey Grebennikov <<a href="mailto:agrebennikov@mirantis.com" target="_blank">agrebennikov@mirantis.com</a>><br>
Reply: OpenStack Development Mailing List (not for usage questions)<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack<wbr>.org</a>><br>
Date: December 5, 2016 at 12:22:09<br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openst<wbr>ack.org</a> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack<wbr>.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. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="m_-3503210754392994038m_1166677766468133215gmail-"><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="m_-3503210754392994038m_1166677766468133215gmail-"><br></span></blockquote></div></div><div>Sorry that I didn't mention this in the beginning.</div><div>Yes, it is supposed to be fernet tokens installation for sure, UUID will not work by default, PKI is deprecated. Keys are supposed to be synchronized. Without it multi-site will never work even if I replicate the database.</div><div>This is what I started from about half a year ago immediately after receiving the usecase. I created 2 clouds, replicated the key, set up each Keystone to know about both sites as Regions, made project IDs same, and voilla - having global LDAP for authentication in place I could even switch between these regions within one Horizon session. So that one works.</div><div><br></div><div>Next, the ability to store projects in LDAP was removed 2 releases ago. From my personal opinion (and in fact not just mine but hundreds of other users as well) this was one of the biggest mistakes.</div><div>This is one of the major questions from my side to the community - if it was always possible to store project IDs in the external provider, and if it is still possible to do it for the userIDs - what is the point of preventing it now?</div><span><div><br></div></span></div></div></div></blockquote><div><br></div></div></div><div>I want to go on record that we (the maintainers of Keystone) and those of us who have spent a significant amount of time working through the LDAP code came to the community and asked who used this feature (Through many channels). There were exactly 2 responses of deployers using LDAP to store project IDs. Both of them were open or actively working towards moving projects into SQL (or alternatively, developing their own "resource" store). The LDAP backend for resources (projects/domains) was poorly supported, had limited interest from the community (for improvements) and generally was a very large volume of work to bring up to being on-par with the SQL implementation.</div><div><br></div><div>Without the interest of stakeholders (and with few/no active users), it wasn't feasible to continue to maintain it. There is nothing stopping you from storing projects externally. You can develop a driver to communicate with the backend of your choice. The main reason projects were stored in LDAP was due to the "all or nothing" original design of "KeystoneV2 "; you could store users in LDAP but you also had to store projects, role assignments, etc. Most deployments only wanted Users in LDAP but suffered through the rest because it was required (there was no split of User, Resource, and Assignment like there is today).</div><div><div class="h5"><div><br></div></div></div></div></div></div></blockquote><div>Maybe it was the time when I haven't yet actively participated in the community bringing issues.</div><div>I personally participated in at least 5 projects within the last 2 years where we stored assignments/projects/roles in LDAP or AD, and All customers were really frustrated that the functionality is going to be removed.</div><div>Neither of them wanted to manage OpenStack environment separately from the rest of their enterprise platforms.</div><div>Even today, since almost Every production cloud is using LDAP/AD as the source of authentication, the major concern from the customers is that the assignments cannot be stored in LDAP.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="m_-3503210754392994038m_1166677766468133215gmail-">
> 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="m_-3503210754392994038m_1166677766468133215gmail-"><br></span></blockquote><div><br></div></span><div>They may. Depending on what is currently being used in production. It is not always so easy to completely refactor external tooling, especially if they are proprietary or semi-proprietary.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="m_-3503210754392994038m_1166677766468133215gmail-">
> 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></blockquote></span><div>Not sure I'm following.... In essence it is "replication". It should be the same. So when Glance brings the image to another region (from the Particular project) - it expects this project to exist. </div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="m_-3503210754392994038m_1166677766468133215gmail-"><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="m_-3503210754392994038m_1166677766468133215gmail-"><br></span></blockquote></span><div>See above - no other way to do it. Replication of the DB is not only bad way to deal with it - there is no guarantee that broken tables from one region will stay only in their own region. You have to start dealing with decisions like "which region is supposed to be the main one", because there is no "main" one. You'll start getting your regions frozen when they lose  connectivity to each others etc (this is about 2 regions architecture and there is no quorum).</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="m_-3503210754392994038m_1166677766468133215gmail-">
> 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></blockquote><div><br></div></span><div>This is completely opposite from what I meant. What I say is >> concerns from cores (purely developer's opinions) << where the essence was about "there is no complaints yet from Not developers". I'm sorry if I hurt your feeling, but when I keep hearing "go replicate your db" instead of discussing real cons, this makes me hyper upset as well.</div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class="m_-3503210754392994038m_1166677766468133215gmail-"><br>
> Please help me to bring it to life ;)<br>
<br>
</span>Please give us more detail and convince us to help you. :)<br></blockquote><div><br></div></span><div>Hope that's enough. Thanks a lot for such extended response. </div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
[1]: <a href="https://theagileadmin.com/what-is-devops/" rel="noreferrer" target="_blank">https://theagileadmin.com/what<wbr>-is-devops/</a><br>
<br>
--<br>
Ian Cordasco<br>
<div class="m_-3503210754392994038m_1166677766468133215gmail-HOEnZb"><div class="m_-3503210754392994038m_1166677766468133215gmail-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.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></span></div><br><br clear="all"><span><div><br></div>-- <br><div class="m_-3503210754392994038m_1166677766468133215gmail_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>
</span></div></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.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></div></div><br></div></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><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>