Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
On 15/08/15 00:23, Rich Megginson wrote: 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. I've broken down https://review.openstack.org/212523 (now abandoned) in three pieces: The first 2 ones can be backported to Kilo. 1. https://review.openstack.org/213598 https://review.openstack.org/213938 2. https://review.openstack.org/213603 Once 1. gets merged in Liberty, we'll be able to cherry pick it. That won't necessarily fix the issue but it won't hurt but more importantly it's making things a bit easier with clear separation between url assignments and getting endpoints. The last and next coming piece removes the API version numbers from the Endpoints. Meanwhile that one won't be 'back-portable' unless OSC version on Kilo gets bumped up which not likely to happen. I hope it helps. Let's take it from there and see what else we can do to address those v2/v3.0 issues. Cheers, Gilles -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/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:
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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. 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,
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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? -Matthew On Fri, Aug 14, 2015 at 3:47 PM, Gilles Dubreuil 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; 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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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. 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 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 wrote: With
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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. 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 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:
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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/ I don't think so. Keystone requires the version suffix /v2.0 or /v3. 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/ It does, if it can determine from the given authentication arguments if it can do v3 or v2.0. 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. 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. Additionally, creating endpoints/users/roles shouldbe possible via openrc alone. Yes. 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. 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 On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson 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 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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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/ 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/ 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) 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. Additionally, creating endpoints/users/roles shouldbe possible via openrc alone. It's not possible to write single node tests that can demonstrate this functionality, which is why it probably went undetected for so long. 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 On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson 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 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://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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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. -Matthew On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius 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://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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
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 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://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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
On 07/30/2015 08:53 AM, Matthew Mosesohn wrote: Hi Rich, Sorry, I meant to link [0] to https://bugs.launchpad.net/keystone/+bug/1470635 More responses inline. On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson rmegg...@redhat.com wrote: There is a patch upstream[1] that enables V3 service endpoint creation, but v2.0 users/clients will not see these endpoints. Right. I'm not sure what the problem is - v3 clients can see the endpoints created with v2. But not vice versa. But you said We are using Keystone v2.0 API everywhere currently. - Are you trying to move to use v3? Not yet. I'm still not sure what the problem is. Are you trying to move to use v3 for auth, and use v3 resources like domains? No. Avoiding that is better for now. Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers, updating ENV with 2 vars: OS_IDENTITY_API_VERSION=3 OS_AUTH_URL=$(echo $OLD_OS_AUTH_URL | sed -e s'/v2.0/v3/') or their equivalent in command line parameters I don't understand. When you say v3 keystone providers are you talking about the puppet-keystone openstack.rb providers? If so, they already do something similar to the above. Yes, the puppet-keystone openstack.rb providers. Almost, except they don't update the identity_api_version. It just passes the version from ENV or $HOME/openrc https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack/credentials.rb Ok, I see. The intention of that code is that, if you specify something in ENV/openrc, it will override the default settings in the provider. What if the puppet-keystone openstack providers did not allow you to override the api version/url version with ENV/openrc? Would that solve the problem? Option 2: Update to v3 Identity API for all services and accept the unmerged patch[1]. This route requires the most disruptive changes because of [0] and I would like to avoid this. I don't understand why you need [1] which makes keystone_endpoint use the v3 api. v3 clients can see endpoints created with the v2 api. Updating all clients to v3 is more effort at this point and v3 keystone is not targeted for Fuel 7.0. Option 3: Revert puppet-keystone to version 5.1.0 which is before v3 became mandatory. I'd like to see what is possible with Option 1 because it should be possible to use the existing providers in puppet-keystone master without too many hoops to make them all work cleanly. I'd really prefer being able to provide all these parameters to the keystone provider, rather than relying on the /root/openrc file or exporting shell vars, but getting this issue unstuck is really the most important. I'm still not sure what the issue is, what you are prevented from doing. The issue, concisely, is creating service_endpoints with v2.0 API and other keystone resources with v3 API using one /root/openrc file. __ 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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
On 07/30/2015 08:24 AM, Matthew Mosesohn wrote: Hi all, It seems that I've reached an impasse with https://review.openstack.org/#/q/topic:bp/detach-components-from-controllers,n,z in Keystone with regards to Kilo puppet manifests. One of the objectives is the ability to deploy Keystone on a separate node from the controllers. Here is what we know: We are using Keystone v2.0 API everywhere currently. Most Keystone providers for users, services, etc, use V3 API through openstackclient Keystone provider for service endpoints is still on V2. This is because v2.0 clients can't see v3 endpoints. It's by design to not be forward compatible[0]. I don't understand - [0] is a link to an ansible review? There is a patch upstream[1] that enables V3 service endpoint creation, but v2.0 users/clients will not see these endpoints. Right. I'm not sure what the problem is - v3 clients can see the endpoints created with v2. Note that in Keystone, resources like roles, services, and endpoints are _not_ domain scoped, and therefore do not need to use the v3 api to CRUD. Identity v2 and v3 behavior of openstackclient are vastly different. There is nothing backward/forward compatible among the two, so it's a hassle to deal with them in parallel. openstackclient fails on v3 parameters unless version 3 is explicitly enabled. But you said We are using Keystone v2.0 API everywhere currently. - Are you trying to move to use v3? What we can do to go forward? I'm still not sure what the problem is. Are you trying to move to use v3 for auth, and use v3 resources like domains? Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers, updating ENV with 2 vars: OS_IDENTITY_API_VERSION=3 OS_AUTH_URL=$(echo $OLD_OS_AUTH_URL | sed -e s'/v2.0/v3/') or their equivalent in command line parameters I don't understand. When you say v3 keystone providers are you talking about the puppet-keystone openstack.rb providers? If so, they already do something similar to the above. Option 2: Update to v3 Identity API for all services and accept the unmerged patch[1]. This route requires the most disruptive changes because of [0] and I would like to avoid this. I don't understand why you need [1] which makes keystone_endpoint use the v3 api. v3 clients can see endpoints created with the v2 api. Option 3: Revert puppet-keystone to version 5.1.0 which is before v3 became mandatory. I'd like to see what is possible with Option 1 because it should be possible to use the existing providers in puppet-keystone master without too many hoops to make them all work cleanly. I'd really prefer being able to provide all these parameters to the keystone provider, rather than relying on the /root/openrc file or exporting shell vars, but getting this issue unstuck is really the most important. I'm still not sure what the issue is, what you are prevented from doing. [0] https://review.openstack.org/#/c/196943/ [1] https://review.openstack.org/#/c/178456/24 Best Regards, Matthew Mosesohn __ 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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
Hi Rich, Sorry, I meant to link [0] to https://bugs.launchpad.net/keystone/+bug/1470635 More responses inline. On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson rmegg...@redhat.com wrote: There is a patch upstream[1] that enables V3 service endpoint creation, but v2.0 users/clients will not see these endpoints. Right. I'm not sure what the problem is - v3 clients can see the endpoints created with v2. But not vice versa. But you said We are using Keystone v2.0 API everywhere currently. - Are you trying to move to use v3? Not yet. I'm still not sure what the problem is. Are you trying to move to use v3 for auth, and use v3 resources like domains? No. Avoiding that is better for now. Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers, updating ENV with 2 vars: OS_IDENTITY_API_VERSION=3 OS_AUTH_URL=$(echo $OLD_OS_AUTH_URL | sed -e s'/v2.0/v3/') or their equivalent in command line parameters I don't understand. When you say v3 keystone providers are you talking about the puppet-keystone openstack.rb providers? If so, they already do something similar to the above. Yes, the puppet-keystone openstack.rb providers. Almost, except they don't update the identity_api_version. It just passes the version from ENV or $HOME/openrc https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack/credentials.rb Option 2: Update to v3 Identity API for all services and accept the unmerged patch[1]. This route requires the most disruptive changes because of [0] and I would like to avoid this. I don't understand why you need [1] which makes keystone_endpoint use the v3 api. v3 clients can see endpoints created with the v2 api. Updating all clients to v3 is more effort at this point and v3 keystone is not targeted for Fuel 7.0. Option 3: Revert puppet-keystone to version 5.1.0 which is before v3 became mandatory. I'd like to see what is possible with Option 1 because it should be possible to use the existing providers in puppet-keystone master without too many hoops to make them all work cleanly. I'd really prefer being able to provide all these parameters to the keystone provider, rather than relying on the /root/openrc file or exporting shell vars, but getting this issue unstuck is really the most important. I'm still not sure what the issue is, what you are prevented from doing. The issue, concisely, is creating service_endpoints with v2.0 API and other keystone resources with v3 API using one /root/openrc file. __ 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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
The problem appears to be much more concise. The provider sets identity_api_version okay, but doesn't alter OS_AUTH_URL api version. That's the only reason why this is breaking. It is broken in 2 places: in openstacklib's credentials class and in keystone base provider. The keystone auth_endpoint logic seems to just duplicate that of openstacklib's credentials class, so I think it would make sense to consolidate that. I will prepare a patch to puppet-keystone and puppet-openstacklib to address this. On Thu, Jul 30, 2015 at 6:14 PM, Rich Megginson rmegg...@redhat.com wrote: On 07/30/2015 08:53 AM, Matthew Mosesohn wrote: Hi Rich, Sorry, I meant to link [0] to https://bugs.launchpad.net/keystone/+bug/1470635 More responses inline. On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson rmegg...@redhat.com wrote: There is a patch upstream[1] that enables V3 service endpoint creation, but v2.0 users/clients will not see these endpoints. Right. I'm not sure what the problem is - v3 clients can see the endpoints created with v2. But not vice versa. But you said We are using Keystone v2.0 API everywhere currently. - Are you trying to move to use v3? Not yet. I'm still not sure what the problem is. Are you trying to move to use v3 for auth, and use v3 resources like domains? No. Avoiding that is better for now. Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers, updating ENV with 2 vars: OS_IDENTITY_API_VERSION=3 OS_AUTH_URL=$(echo $OLD_OS_AUTH_URL | sed -e s'/v2.0/v3/') or their equivalent in command line parameters I don't understand. When you say v3 keystone providers are you talking about the puppet-keystone openstack.rb providers? If so, they already do something similar to the above. Yes, the puppet-keystone openstack.rb providers. Almost, except they don't update the identity_api_version. It just passes the version from ENV or $HOME/openrc https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack/credentials.rb Ok, I see. The intention of that code is that, if you specify something in ENV/openrc, it will override the default settings in the provider. What if the puppet-keystone openstack providers did not allow you to override the api version/url version with ENV/openrc? Would that solve the problem? Option 2: Update to v3 Identity API for all services and accept the unmerged patch[1]. This route requires the most disruptive changes because of [0] and I would like to avoid this. I don't understand why you need [1] which makes keystone_endpoint use the v3 api. v3 clients can see endpoints created with the v2 api. Updating all clients to v3 is more effort at this point and v3 keystone is not targeted for Fuel 7.0. Option 3: Revert puppet-keystone to version 5.1.0 which is before v3 became mandatory. I'd like to see what is possible with Option 1 because it should be possible to use the existing providers in puppet-keystone master without too many hoops to make them all work cleanly. I'd really prefer being able to provide all these parameters to the keystone provider, rather than relying on the /root/openrc file or exporting shell vars, but getting this issue unstuck is really the most important. I'm still not sure what the issue is, what you are prevented from doing. The issue, concisely, is creating service_endpoints with v2.0 API and other keystone resources with v3 API using one /root/openrc file. __ 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 __ 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
Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints
On 07/30/2015 10:54 AM, Matthew Mosesohn wrote: The problem appears to be much more concise. The provider sets identity_api_version okay, but doesn't alter OS_AUTH_URL api version. That's the only reason why this is breaking. It is broken in 2 places: in openstacklib's credentials class and in keystone base provider. The keystone auth_endpoint logic seems to just duplicate that of openstacklib's credentials class, so I think it would make sense to consolidate that. I will prepare a patch to puppet-keystone and puppet-openstacklib to address this. Ok. Please add me to the reviews. On Thu, Jul 30, 2015 at 6:14 PM, Rich Megginson rmegg...@redhat.com wrote: On 07/30/2015 08:53 AM, Matthew Mosesohn wrote: Hi Rich, Sorry, I meant to link [0] to https://bugs.launchpad.net/keystone/+bug/1470635 More responses inline. On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson rmegg...@redhat.com wrote: There is a patch upstream[1] that enables V3 service endpoint creation, but v2.0 users/clients will not see these endpoints. Right. I'm not sure what the problem is - v3 clients can see the endpoints created with v2. But not vice versa. But you said We are using Keystone v2.0 API everywhere currently. - Are you trying to move to use v3? Not yet. I'm still not sure what the problem is. Are you trying to move to use v3 for auth, and use v3 resources like domains? No. Avoiding that is better for now. Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers, updating ENV with 2 vars: OS_IDENTITY_API_VERSION=3 OS_AUTH_URL=$(echo $OLD_OS_AUTH_URL | sed -e s'/v2.0/v3/') or their equivalent in command line parameters I don't understand. When you say v3 keystone providers are you talking about the puppet-keystone openstack.rb providers? If so, they already do something similar to the above. Yes, the puppet-keystone openstack.rb providers. Almost, except they don't update the identity_api_version. It just passes the version from ENV or $HOME/openrc https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack/credentials.rb Ok, I see. The intention of that code is that, if you specify something in ENV/openrc, it will override the default settings in the provider. What if the puppet-keystone openstack providers did not allow you to override the api version/url version with ENV/openrc? Would that solve the problem? Option 2: Update to v3 Identity API for all services and accept the unmerged patch[1]. This route requires the most disruptive changes because of [0] and I would like to avoid this. I don't understand why you need [1] which makes keystone_endpoint use the v3 api. v3 clients can see endpoints created with the v2 api. Updating all clients to v3 is more effort at this point and v3 keystone is not targeted for Fuel 7.0. Option 3: Revert puppet-keystone to version 5.1.0 which is before v3 became mandatory. I'd like to see what is possible with Option 1 because it should be possible to use the existing providers in puppet-keystone master without too many hoops to make them all work cleanly. I'd really prefer being able to provide all these parameters to the keystone provider, rather than relying on the /root/openrc file or exporting shell vars, but getting this issue unstuck is really the most important. I'm still not sure what the issue is, what you are prevented from doing. The issue, concisely, is creating service_endpoints with v2.0 API and other keystone resources with v3 API using one /root/openrc file. __ 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 __ 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
