Description of problem: As per the OSP-API matrix, the glance version should be v2.3 and keystone should be v3 as the default api version for OSP10. We are not seeing this. We do see a Cinder V3 endpoint, although the client is using v2. Version-Release number of selected component (if applicable): OSP10 GA root@r7-13g-controller-0 ~]# rpm -qa | grep keystone python-keystoneclient-3.5.0-1.el7ost.noarch python-keystonemiddleware-4.9.0-1.el7ost.noarch python-keystoneauth1-2.12.2-1.el7ost.noarch python-keystone-10.0.0-4.el7ost.noarch openstack-keystone-10.0.0-4.el7ost.noarch puppet-keystone-9.4.0-2.el7ost.noarch root@r7-13g-controller-0 ~]# rpm -qa | grep glance puppet-glance-9.4.0-2.el7ost.noarch python-glance-store-0.18.0-2.el7ost.noarch python-glance-13.0.0-1.el7ost.noarch python-glanceclient-2.5.0-1.el7ost.noarch openstack-glance-13.0.0-1.el7ost.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The command Rajini ran to get the versions is: 1) source overcloudrc 2) openstack endpoint list --long This shows: (kind of hard to display here) [osp_admin@r7-director ~]$ openstack endpoint list --long +-------------------------------+-----------+--------------+----------------+-------------------------------+-------------------------------+-------------------------------+ | ID | Region | Service Name | Service Type | PublicURL | AdminURL | InternalURL | +-------------------------------+-----------+--------------+----------------+-------------------------------+-------------------------------+-------------------------------+ | c8e4e44263d543938d10f0e761b93 | regionOne | heat | orchestration | http://100.82.37.60:8004/v1/% | http://192.168.140.60:8004/v1 | http://192.168.140.60:8004/v1 | | 71d | | | | (tenant_id)s | /%(tenant_id)s | /%(tenant_id)s | | 35f96d6892fa4e729ec174caaf78b | regionOne | keystone | identity | http://100.82.37.60:5000/v2.0 | http://192.168.120.60:35357/v | http://192.168.140.60:5000/v2 | | d4b | | | | | 2.0 | .0 | | bfc1cf7ca70d401681ff1527706ac | regionOne | heat-cfn | cloudformation | http://100.82.37.60:8000/v1 | http://192.168.140.60:8000/v1 | http://192.168.140.60:8000/v1 | | fbd | | | | | | | | 8cdbc0e67809402cb39dd1a6d957b | regionOne | ceilometer | metering | http://100.82.37.60:8777 | http://192.168.140.60:8777 | http://192.168.140.60:8777 | | 4a2 | | | | | | | | d50d746ef5f549e59bee10440bd91 | regionOne | aodh | alarming | http://100.82.37.60:8042 | http://192.168.140.60:8042 | http://192.168.140.60:8042 | | f65 | | | | | | | | cde521ddcdf94b389813b6962e09f | regionOne | cinderv3 | volumev3 | http://100.82.37.60:8776/v3/% | http://192.168.140.60:8776/v3 | http://192.168.140.60:8776/v3 | | 53d | | | | (tenant_id)s | /%(tenant_id)s | /%(tenant_id)s | | 8c17a47a808e4208b106e992c4d76 | regionOne | swift | object-store | http://100.82.37.60:8080/swif | http://192.168.170.60:8080/sw | http://192.168.170.60:8080/sw | | f3f | | | | t/v1 | ift/v1 | ift/v1 | | a4ebb3da15c440e2b9b4efc185aa5 | regionOne | gnocchi | metric | http://100.82.37.60:8041 | http://192.168.140.60:8041 | http://192.168.140.60:8041 | | c60 | | | | | | | | de419b8bb104470ca85317755e2ef | regionOne | glance | image | http://100.82.37.60:9292 | http://192.168.170.60:9292 | http://192.168.170.60:9292 | | d4f | | | | | | | | 0327c22a3baa4cb58718634b73a68 | regionOne | neutron | network | http://100.82.37.60:9696 | http://192.168.140.60:9696 | http://192.168.140.60:9696 | | 6d2 | | | | | | | | 3302d7fb1f7d48e2adf61700f86a2 | regionOne | cinder | volume | http://100.82.37.60:8776/v1/% | http://192.168.140.60:8776/v1 | http://192.168.140.60:8776/v1 | | ea0 | | | | (tenant_id)s | /%(tenant_id)s | /%(tenant_id)s | | 3a01aac2f1464f1698ac2e546d19a | regionOne | cinderv2 | volumev2 | http://100.82.37.60:8776/v2/% | http://192.168.140.60:8776/v2 | http://192.168.140.60:8776/v2 | | 5a0 | | | | (tenant_id)s | /%(tenant_id)s | /%(tenant_id)s | | befdc8c805214253abae970e11d89 | regionOne | nova | compute | http://100.82.37.60:8774/v2.1 | http://192.168.140.60:8774/v2 | http://192.168.140.60:8774/v2 | | 471 | | | | | .1 | .1 | +-------------------------------+-----------+--------------+----------------+-------------------------------+-------------------------------+-------------------------------+
Let me add a bit of clarity here. 1. We need to make sure that the versions of APIs for each project needed for latest refstack (interoperability suite) is supported by OSP 10. And preferably that version should default. 2. Second is dependency of Cloudforms version on API versions of AODH, Gnocchi, Painko & Keystone. Not sure if there is dependency on any other projects. 3. Dependency of OpenShift on specific version of projects APIs, especially for neutron, nova and cinder. While this is not specific to 3 projects mentioned in BZ, this is the rationale for ask for
(In reply to Rajini Ram from comment #0) > Description of problem: > > As per the OSP-API matrix, the glance version should be v2.3 and keystone > should be v3 as the default api version for OSP10. We are not seeing this. > We do see a Cinder V3 endpoint, although the client is using v2. Can you elaborate a little further in each case? Part of the problem in communicating exactly what should be fixed where is that increasingly the endpoint list isn't actually that meaningful for a variety of services because it is unversioned in the URL. Instead you have to actually query the endpoint to get the versions supported. Poking a test install which is admittedly PackStack based for the Glance endpoint for example I get: (u'CURRENT', u'v2.4') (u'SUPPORTED', u'v2.3') (u'SUPPORTED', u'v2.2') (u'SUPPORTED', u'v2.1') (u'SUPPORTED', u'v2.0') (u'DEPRECATED', u'v1.1') (u'DEPRECATED', u'v1.0') Is the request that instead of v2.4 we should fix to v2.3 for Glance because that is what was current at the point in time the data in the spreadsheet was extracted? Similarly for Cinder you mention you see v3 but the client negotiates to v2, is this also what you are seeing for keystone? Are you using the individual per-project clients (glance, keystone) or the openstack unified client (openstack)?
I was using the unified openstack client. I don't have packstack, so I'm not able to comment on that. List of things I see wrong on the OSP installation 1. Overcloudrc using the v2 keystone 2. We should atleast see the V3 endpoints for the cinder and keystone defined in the list. Its missing 3. Checked the nova.conf, it is not using v3 endpoints either Let me know if you need any other info
(In reply to Rajini Ram from comment #4) > I was using the unified openstack client. I don't have packstack, so I'm not > able to comment on that. The PackStack piece is somewhat irrelevant, if I ran the script against a Glance endpoint deployed by OSP-d I'd get the same result (a list of the versions it supports). What I was getting at is it's not clear to me what the issue is with the Glance setup here, as it supports all versions 2.0-2.4. What I'm working on is a script to automate extraction/publication of the supported API versions for a given deployment, this involves not just checking the endpoint URLs but actually querying them to see which versions they support. This will be more accurate than what I believe has added to the confusion here which was a one time extract prior to the finalization of the given release. > List of things I see wrong on the OSP installation > > 1. Overcloudrc using the v2 keystone Ack, it looks like this was fixed for the RC files generated by Horizon under Bug # 1279735 but not the overcloudrc created by Director. > 2. We should atleast see the V3 endpoints for the cinder and keystone > defined in the list. Its missing The endpoint list output pasted in comment #1 includes a v3 endpoint for Cinder. You may however be hitting this on the client side: https://bugzilla.redhat.com/show_bug.cgi?id=1421014 https://bugs.launchpad.net/python-cinderclient/+bug/1546280 Need to confirm whether Keystone requires explicit v2/v3 endpoints, most services are moving to "version-less" endpoints in the catalog and the clients negotiate based on the response. E.g. if I query the Keystone URL without a v2 or v3 appendage to the URL I get a response that indicates support for both v3.7 and v2.0: $ curl http://192.168.1.1:5000 {"versions": {"values": [{"status": "stable", "updated": "2016-10-06T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v3+json"}], "id": "v3.7", "links": [{"href": "http://10.15.24.125:5000/v3/", "rel": "self"}]}, {"status": "deprecated", "updated": "2016-08-04T00:00:00Z", "media-types": [{"base": "application/json", "type": "application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": [{"href": "http://10.15.24.125:5000/v2.0/", "rel": "self"}, {"href": "http://docs.openstack.org/", "type": "text/html", "rel": "describedby"}]}]}} So it is not clear to me whether the right approach is to have both v2.0 and v3 entries in the catalog, or to collapse into a version-less endpoint like the above. This would be for the Keystone folks to confirm. > 3. Checked the nova.conf, it is not using v3 endpoints either Ack. Sean I think the most sensible thing from here is to use this as a tracker and raise multiple bugs as dependencies, there are a couple of different DFGs that need to own cleaning up bits and pieces of this.
Changed the bug summary to tracker, please add the relevant bugs to this one. Sean
(In reply to arkady kanevsky from comment #2) > Let me add a bit of clarity here. > 1. We need to make sure that the versions of APIs for each project needed > for latest refstack (interoperability suite) is supported by OSP 10. And > preferably that version should default. I checked in on this, the latest refstack result for RHOSP 10 is here which indicates compliance: https://refstack.openstack.org/#/results/14fe7246-a961-41f5-91b9-0bd1c30f2ab4
Split these into 4 Bzs https://bugzilla.redhat.com/show_bug.cgi?id=1434923 https://bugzilla.redhat.com/show_bug.cgi?id=1434928 https://bugzilla.redhat.com/show_bug.cgi?id=1434929 https://bugzilla.redhat.com/show_bug.cgi?id=1434931
All 4 BZs submitted and linked this one as 'depends on'
Closing out this BZ as the several BZs that it depends on are all now closed errata.