[openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

Gilles Dubreuil gilles at redhat.com
Fri Aug 14 12:47:25 UTC 2015



On 14/08/15 20:45, Gilles Dubreuil wrote:
> 
> 
> On 13/08/15 23:29, Rich Megginson wrote:
>> On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
>>> Hi Matthew,
>>>
>>> On 11/08/15 01:14, Rich Megginson wrote:
>>>> On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
>>>>> Sorry to everyone for bringing up this old thread, but it seems we may
>>>>> need more openstackclient/keystone experts to settle this.
>>>>>
>>>>> I'm referring to the comments in
>>>>> https://review.openstack.org/#/c/207873/
>>>>> Specifically comments from Richard Megginson and Gilles Dubreuil
>>>>> indicating openstackclient behavior for v3 keystone API.
>>>>>
>>>>>
>>>>> A few items seem to be under dispute:
>>>>> 1 - Keystone should be able to accept v3 requests at
>>>>> <http://keystone-server:5000/>http://keystone-server:5000/
>>>> I don't think so.  Keystone requires the version suffix "/v2.0" or
>>>> "/v3".
>>>>
>>> Yes, if the public endpoint is set without a version then the service
>>> can deal with either version.
>>>
>>> http://paste.openstack.org/raw/412819/
>>>
>>> That is not true for the admin endpoint (authentication is already done,
>>> the admin services deals only with tokens), at least for now, Keystone
>>> devs are working on it.
>>
>> I thought it worked like this - the openstack cli will infer from the
>> arguments if it should do v2 or v3 auth.  In the above case for v3,
>> since you specify the username/password, osc knows it has to use
>> password auth (as opposed to token auth), and since all of the required
>> v3 arguments are provided (v3 api version, domains for user/project), it
>> can use v3 password auth.  It knows it has to use the "/v3/auth/token"
>> path to get a token.
>>
>> Similarly for v2, since it only has username/password, no v3 api or v3
>> domain arguments, it knows it has to use v2 password auth.  It knows it
>> has to use "/v2.0/token" to get a token.
>>
>> With the puppet-keystone code, since it uses TOKEN/URL, osc cannot infer
>> if it can use v2 or v3, so it requires the "/v2.0" or "/v3" suffix, and
>> the api version.
>>
> 
> First of my apologies because I confused admin enpdoint with the admin
> service (or whatever that's dubbed).
> 
> As of Keystone v3 (not the API, the latest version of Keystone which
> supports both API v2.0 and V3), the OS_AUTH_URL doesn't need the
> version. That can be effectively any of the endpoints, either the main
> (or public) by default on port 5000 or the admin by default on port
> 35357, the third one internal pointing to either of the first two ones.
> 
> This is a behavior at Keystone level not at the OSC. I mean OSC will
> just reflect the http-api behavior.
> 
> Now the admin service, the one needed for the OS-TOKEN (used for
> bootstrapping) needs a URL (OS_URL) with a version to work.
> 
> ATM, the issue with puppet keystone is that endpoints, OS_URL and
> OS_AUTH_URL are walking on each others.
> 
> 

My latest update on this one, is that I found out while testing beaker
which is using OSC 1.0.3 is not handling OS_AUTH_URL properly.

I had been testing with OSC 1.5.1 and now latest 1.6.1 from Dolerean
repo, where the version-less URLs are working, but not with OSC 1.0.1:

----------------------

# cat openrc
export OS_AUTH_URL=http://127.0.0.1:5000
export OS_USERNAME=adminv3
export OS_PASSWORD=testing
export OS_PROJECT_NAME=openstackv3
export OS_USER_DOMAIN_NAME=admin_domain
export OS_PROJECT_DOMAIN_NAME=admin_domain
export OS_IDENTITY_API_VERSION="3"

# openstack endpoint list -f csv
"ID","Region","Service Name","Service Type","Enabled","Interface","URL"
"87b7db1b23df487bb4ec96de5aa3c271","RegionOne","keystone","identity",True,"internal","http://127.0.0.1:5000"
"d9b345109d8a4320ac0dd832d2532cce","RegionOne","keystone","identity",True,"admin","http://127.0.0.1:35357"
"f3a579a64f0241ef9aef3dc983e0fd4a","RegionOne","keystone","identity",True,"public","http://127.0.0.1:5000"

----------------------

# cat openrc_v2
export OS_AUTH_URL=http://[::1]:5000
export OS_USERNAME=admin
export OS_PASSWORD=a_big_secret
export OS_TENANT_NAME=openstack

# openstack endpoint list -f csv --long
"ID","Region","Service Name","Service
Type","PublicURL","AdminURL","InternalURL"
"cf8825c44bd041109d5c7438ba9db8f3","RegionOne","keystone","identity","http://127.0.0.1:5000","http://127.0.0.1:35357","http://127.0.0.1:5000"




>>>
>>>>> 2 - openstackclient should be able to interpret v3 requests and append
>>>>> "v3/" to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL
>>>>> if it is set as
>>>>> OS_AUTH_URL=<http://keystone-server.5000/>http://keystone-server.5000/
>>>> It does, if it can determine from the given authentication arguments if
>>>> it can do v3 or v2.0.
>>>>
>>> It effectively does, again, assuming the path doesn't contain a version
>>> number (x.x.x.x:5000)
>>>
>>>>> 3 - All deployments require /etc/keystone/keystone.conf with a token
>>>>> (and not simply use openrc for creating additional endpoints, users,
>>>>> etc beyond keystone itself and an admin user)
>>>> No.  What I said about this issue was "Most people using
>>>> puppet-keystone, and realizing Keystone resources on nodes that are not
>>>> the Keystone node, put a /etc/keystone/keystone.conf on that node with
>>>> the admin_token in it."
>>>>
>>>> That doesn't mean the deployment requires /etc/keystone/keystone.conf.
>>>> It should be possible to realize Keystone resources on non-Keystone
>>>> nodes by using ENV or openrc or other means.
>>>>
>>> Agreed. Also keystone.conf is used only to bootstrap keystone
>>> installation and create admin users, etc.
>>>
>>>
>>>>> I believe it should be possible to set v2.0 keystone OS_AUTH_URL in
>>>>> openrc and puppet-keystone + puppet-openstacklib should be able to
>>>>> make v3 requests sensibly by manipulating the URL.
>>>> Yes.  Because for the puppet-keystone resource providers, they are coded
>>>> to a specific version of the api, and therefore need to be able to
>>>> set/override the OS_IDENTITY_API_VERSION and the version suffix in
>>>> the URL.
>>>>
>>> No. To support V2 and V3, the OS_AUTH_URL must not contain any version
>>> in order.
>>>
>>> The less we deal with the version number the better!
>>>
>>>>> Additionally, creating endpoints/users/roles shouldbe possible via
>>>>> openrc alone.
>>>> Yes.
>>>>
>>> Yes, the openrc variables are used, if not available then the service
>>> token from the keystone.conf is used.
>>>
>>>>> It's not possible to write single node tests that can demonstrate this
>>>>> functionality, which is why it probably went undetected for so long.
>>>> And since this is supported, we need tests for this.
>>> I'm not sure what's the issue besides the fact keystone_puppet doesn't
>>> generate a RC file once the admin user has been created. That is left to
>>> be done by the composition layer. Although we might want to integrate
>>> that.
>>>
>>> If that issue persists, assuming the AUTH_URL is free for a version
>>> number and having an openrc in place, we're going to need a bug number
>>> to track the investigation.
>>>
>>>>> If anyone can speak up on these items, it could help influence the
>>>>> outcome of this patch.
>>>>>
>>>>> Thank you for your time.
>>>>>
>>>>> Best Regards,
>>>>> Matthew Mosesohn
>>>
>>> Thanks,
>>> Gilles
>>>
>>>>> On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson <rmeggins at redhat.com
>>>>> <mailto:rmeggins at redhat.com>> wrote:
>>>>>
>>>>>      On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:
>>>>>
>>>>>          Jesse, thanks for raising this. Like you, I should just track
>>>>>          upstream
>>>>>          and wait for full V3 support.
>>>>>
>>>>>          I've taken the quickest approach and written fixes to
>>>>>          puppet-openstacklib and puppet-keystone:
>>>>>          https://review.openstack.org/#/c/207873/
>>>>>          https://review.openstack.org/#/c/207890/
>>>>>
>>>>>          and again to Fuel-Library:
>>>>>          https://review.openstack.org/#/c/207548/1
>>>>>
>>>>>          I greatly appreciate the quick support from the community to
>>>>>          find an
>>>>>          appropriate solution. Looks like I'm just using a weird
>>>>> edge case
>>>>>          where we're creating users on a separate node from where
>>>>>          keystone is
>>>>>          installed and it never got thoroughly tested, but I'm happy
>>>>> to fix
>>>>>          bugs where I can.
>>>>>
>>>>>
>>>>>      Most puppet deployments either realize all keystone resources on
>>>>>      the keystone node, or drop an /etc/keystone/keystone.conf with
>>>>>      admin token onto non-keystone nodes where additional keystone
>>>>>      resources need to be realized.
>>>>>
>>>>>
>>>>>
>>>>>          -Matthew
>>>>>
>>>>>          On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius
>>>>>          <jesse.pretorius at gmail.com <mailto:jesse.pretorius at gmail.com>>
>>>>>          wrote:
>>>>>
>>>>>              With regards to converting all services to use Keystone v3
>>>>>              endpoints, note
>>>>>              the following:
>>>>>
>>>>>              1) swift-dispersion currently does not support consuming
>>>>>              Keystone v3
>>>>>              endpoints [1]. There is a patch merged to master [2] to
>>>>>              fix that, but a
>>>>>              backport to kilo is yet to be done.
>>>>>              2) Each type (internal, admin, public) of endpoint created
>>>>>              with the Keystone
>>>>>              v3 API has its own unique id, unlike with the v2 API where
>>>>>              they're all
>>>>>              created with a single ID. This results in the keystone
>>>>>              client being unable
>>>>>              to read the catalog created via the v3 API when querying
>>>>>              via the v2 API. The
>>>>>              solution is to use the openstack client and to use the v3
>>>>>              API but this
>>>>>              obviously needs to be noted for upgrade impact and
>>>>> operators.
>>>>>              3) When glance is setup to use swift as a back-end,
>>>>>              glance_store is unable
>>>>>              to authenticate to swift when the endpoint it uses is a v3
>>>>>              endpoint. There
>>>>>              is a review to master in progress [3] to fix this which is
>>>>>              unlikely to make
>>>>>              it into kilo.
>>>>>
>>>>>              We (the openstack-ansible/os-ansible-deployment project)
>>>>>              are tracking these
>>>>>              issues and doing tests to figure out all the bits. These
>>>>>              are the bugs we've
>>>>>              hit so far. Also note that there is a WIP patch to gate
>>>>>              purely on Keystone
>>>>>              v3 API's which is planned to become voting (hopefully) by
>>>>>              the end of this
>>>>>              cycle.
>>>>>
>>>>>              [1] https://bugs.launchpad.net/swift/+bug/1468374
>>>>>              [2] https://review.openstack.org/195131
>>>>>              [3] https://review.openstack.org/193422
>>>>>
>>>>>             
>>>>> __________________________________________________________________________
>>>>>
>>>>>              OpenStack Development Mailing List (not for usage
>>>>> questions)
>>>>>              Unsubscribe:
>>>>>             
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>             
>>>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>>>>         
>>>>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>>>>     
>>>>> <http://OpenStack-dev-request@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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list