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?
On Mon, Dec 5, 2016 at 2:43 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote: > -----Original Message----- > From: Andrey Grebennikov <agrebenni...@mirantis.com> > Reply: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Date: December 5, 2016 at 12:22:09 > To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [keystone] Custom ProjectID upon creation > > > Hi keystoners, > > I'm not a keystoner, but I hope youu don't mind my replying. > > > 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. > > Here is the review I'm talking about https://review. > > openstack.org/#/c/403866/ > > > > What I'm trying to cover is multi-region deployment, which includes > > geo-distributed cloud with independent Keystone in every region. > > > > There is a number of use cases for the change: > > 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. > > So this just doesn't sound right to me. You say above that there are > independent Keystone deployments in each region. What token type are > you using that each region could validate a token (assuming project > IDs that are identical across regions) that would do this for > "independent Keystone" deployments? > > Specifically, let's presume you use Keystone's new default of fernet > tokens and you have independently deployed Keystone in each region. > Without synchronizing the keys Keystone uses to generate and validate > fernet tokens, I can't imagine how one token would work across all > regions. This sounds like a lofty goal. > > Further, if Keystone is backed by LDAP, why are there projects being > created in the Keystone database at all? I thought using LDAP as a > backend would avoid that necessity. (Again, I'm not a keystone > developer ;)) > > > 2. Automated tools responsible for statistics collection may access all > > regions using one token (real customer's usecase) > > Why can't the automated tools be updated to talk to each Keystone and > get a token while talking to that region? > > > 3. Glance replication may happen because the images' parameter "owner" > > (which is a project) should be consistent across the regions. > > So, Glance replication doesn't even guarantee identical image IDs > across regions. If Glance's replication isn't working because the > owner project is being synchronized directly, that sounds like a bug > in Glance, not Keystone. > > > What I hear all time - "you have to replicate your database" which from > the > > devops/deployment/operations perspective is totally wrong approach. > > DevOps is a movement [1]. Replicating the database is not pleasant, > no, but it is your better option. I'll repeat, though, why is your > LDAP backed Keystone so reliant on Keystone's DB? > > > 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. > > > > There is a long conversation in the comments of the review, mainly with > > concerns from cores (purely developer's opinions). > > You say that as if developer opinions (the folks who have to > understand and maintain your desired approach) is invalid or > worthless. That's not the case. > > > Please help me to bring it to life ;) > > Please give us more detail and convince us to help you. :) > > [1]: https://theagileadmin.com/what-is-devops/ > > -- > Ian Cordasco > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
