Open Stack

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 <sigmavirus24 at gmail.com> wrote:

> -----Original Message-----
> From: Andrey Grebennikov <agrebennikov at mirantis.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Date: December 5, 2016 at 12:22:09
> To: openstack-dev at lists.openstack.org <openstack-dev at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161205/3a84bbd2/attachment.html>