On 08/14/2015 06:51 AM, Matthew Mosesohn wrote:
Gilles,
I already considered this when looking at another openstackclient
issue. Version 1.0.4 has almost no changes from 1.0.3, which is the
official release for Kilo. Maybe we can get this keystone URL handling
fix backported to the 1.0.X branch of openstackclient?
I think we need some sort of fix in openstacklib and/or puppet-keystone
so that v3 providers that use token auth can replace any "/v2.0" in the
url with "/v3", to override any settings of OS_URL or OS_AUTH_URL in ENV
or openrc.
-Matthew
On Fri, Aug 14, 2015 at 3:47 PM, Gilles Dubreuil <gil...@redhat.com
<mailto:gil...@redhat.com>> wrote:
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";
I don't understand. Is this output supposed to show a problem? Looks
like it is working.
What is the problem? What is the difference of behavior between OSC
1.0.x and OSC 1.5.x?
>>>
>>>>> 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
<rmegg...@redhat.com <mailto:rmegg...@redhat.com>
>>>>> <mailto:rmegg...@redhat.com <mailto:rmegg...@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.pretor...@gmail.com
<mailto:jesse.pretor...@gmail.com>
<mailto:jesse.pretor...@gmail.com <mailto:jesse.pretor...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>>>
>>>>>
<http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>>>
>>>>>
<http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>>>
>>>>>
<http://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://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://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://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://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://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://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
__________________________________________________________________________
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
