Bug 1285975 - Keystone internal api endpoint gets created with the wrong network
Keystone internal api endpoint gets created with the wrong network
Status: CLOSED DUPLICATE of bug 1276567
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-rdomanager-oscplugin (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
unspecified Severity unspecified
: y2
: 7.0 (Kilo)
Assigned To: Giulio Fidente
Depends On:
  Show dependency treegraph
Reported: 2015-11-27 01:15 EST by Graeme Gillies
Modified: 2016-04-18 02:55 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-30 09:06:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 251291 None None None Never

  None (edit)
Description Graeme Gillies 2015-11-27 01:15:16 EST

When doing an overcloud deploy, by default the admin api endpoint for keystone will be created on ctlplane (as is defined in the ServiceNetMap in the overcloud parameters).

However, if you modify the ServiceNetMap to have

KeystoneAdminApiNetwork: external
KeystonePublicApiNetwork: internal_api

(as an example), you will instead get a keystone endpoint-list that looks like the following

$ keystone endpoint-list
/usr/lib/python2.7/site-packages/keystoneclient/shell.py:65: DeprecationWarning: The keystone CLI is deprecated in favor of python-openstackclient. For a Python library, continue using python-keystoneclient.
  'python-keystoneclient.', DeprecationWarning)
|                id                |   region  |                   publicurl                   |                   internalurl                   |                  adminurl                  |            service_id            |   
| 4a595a3ce513480faece1a919ab0ca2f | regionOne |             |             |         | f7f55e73fb974af3990098986b7db15f |   
| 570dbad946a74035a56ceeeb5ef8f180 | regionOne |$(tenant_id)s   |$(tenant_id)s   |$(tenant_id)s | cdfe2ad5bb204a60aa69f97903c1f1eb |   
| 88dc1c8d3d1b4daca57c3d0a70378190 | regionOne |             |             |         | 81744cf6ce434182b03ac516e6563e02 |   
| a533dc1f6c4d4d36a42c55038898e3bc | regionOne | | |        | e49b26683a634ae6a5ca622d6f0db2e6 |   
| b64a025e6e5a4d2b8f4202896724f472 | regionOne |   |   | | 211b1bb1559a40b3bc475e46f8e9c531 |   
| b94fbfbe5f784623b2402ef390674391 | regionOne |         |           |        | e3c894a60d21403b82c78268d41d8cff |   
| c340f5a2bf884627abc894ba31099841 | regionOne |   |   | | adc6567cede6461e8ca0418c99e4a1ee |   
| d0c1411a318347a4882709d599fb985a | regionOne |   |   | | ebe025895e794720bcdf6a29048087bb |   
| d4583cf26d6747b7a332bed761c85964 | regionOne |           |           |        | 8729da0d78fe41b7a6374b6473cb3ac7 |   
| e916d499f0224b36abd1490307c00882 | regionOne |       |        |    | 556c495592684eb4ab0d68c313765f88 |   
| f66092989a8b4918b029cbcb130436ff | regionOne |             |             |         | 0a0ccdc493194ceabcf068304114a784 |   

note how the keystone internal api endpoint is also created on the public network, not internal api.

This seems strange but it looks like (possibly?) that this block

        keystone_ip = service_ips.get('KeystoneAdminVip')
        if not keystone_ip:
            keystone_ip = overcloud_ip


is simply initialising keystone with the internal api as being the value of KeystoneAdminVip ??(apologies if this is incorrect, this is just a lazy read over the code, could be barking up the wrong tree).

Or it looks like there is possibly somewhere that is confusing what network the admin port for keystone is using, and what network that the internal_api for keystone should be.


Comment 2 Giulio Fidente 2015-11-27 04:14:17 EST
hi, can you confirm the expectations here were to have:

publicurl on external
internalurl on internal_api
adminurl on external
Comment 3 Graeme Gillies 2015-11-27 04:18:10 EST
(In reply to Giulio Fidente from comment #2)
> hi, can you confirm the expectations here were to have:
> publicurl on external
> internalurl on internal_api
> adminurl on external

Yes to clarify what I would like (or I would expect) with the setting

      NeutronTenantNetwork: tenant
      CeilometerApiNetwork: internal_api
      MongoDbNetwork: internal_api
      CinderApiNetwork: internal_api
      CinderIscsiNetwork: storage
      GlanceApiNetwork: storage
      GlanceRegistryNetwork: internal_api
      KeystoneAdminApiNetwork: external #this has been changed
      KeystonePublicApiNetwork: internal_api
      NeutronApiNetwork: internal_api
      HeatApiNetwork: internal_api
      NovaApiNetwork: internal_api
      NovaMetadataNetwork: internal_api
      NovaVncProxyNetwork: internal_api
      SwiftMgmtNetwork: storage_mgmt
      SwiftProxyNetwork: storage
      HorizonNetwork: internal_api
      MemcachedNetwork: internal_api
      RabbitMqNetwork: internal_api
      RedisNetwork: internal_api
      MysqlNetwork: internal_api
      CephClusterNetwork: storage_mgmt
      CephPublicNetwork: storage
      ControllerHostnameResolveNetwork: internal_api
      ComputeHostnameResolveNetwork: internal_api
      BlockStorageHostnameResolveNetwork: internal_api
      ObjectStorageHostnameResolveNetwork: internal_api
      CephStorageHostnameResolveNetwork: storage

To give me

keystone publicurl and endpoint on external network
keystone internalurl and endpoint on internal_api network
keystone adminurl and endpoint on external network


Comment 4 Mike Burns 2015-11-30 09:06:24 EST

*** This bug has been marked as a duplicate of bug 1276567 ***

Note You need to log in before you can comment on or make changes to this bug.