← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1377080] Re: Stale endpoint selection logic in keystone client

 

So yes there is the possibility within keystone server to create
multiple services with the same service_type. In this case the service
catalog will only check one of the entries for a matching URL.

My opinion here is that keystone should be hardened to make the
service_type unique. In your example after you have let devstack run you
create another compute service_type and add something new to it. There
is already a compute service_type being deployed by devstack and you
should add your endpoints to that.

In its current state a cloud deployed with multiple service_types will
fail to work so i don't think it is a compatibility issue to shut this
down on the server.

** Also affects: keystone
   Importance: Undecided
       Status: New

** Changed in: python-keystoneclient
   Importance: Undecided => Critical

** Changed in: python-keystoneclient
   Importance: Critical => Undecided

** Changed in: python-keystoneclient
   Importance: Undecided => Wishlist

** Changed in: python-keystoneclient
       Status: In Progress => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1377080

Title:
  Stale endpoint selection logic in keystone client

Status in OpenStack Identity (Keystone):
  New
Status in Python client library for Keystone:
  Opinion

Bug description:
  In V3 endpoint groups from different regions are not grouped. It results in a problem in "url_for":
  it only stores for result endpoints of the last region of all with similar service type.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1377080/+subscriptions


References