Bug 1285975 - Keystone internal api endpoint gets created with the wrong network
Summary: Keystone internal api endpoint gets created with the wrong network
Keywords:
Status: CLOSED DUPLICATE of bug 1276567
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-rdomanager-oscplugin
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: y2
: 7.0 (Kilo)
Assignee: Giulio Fidente
QA Contact: yeylon@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-27 06:15 UTC by Graeme Gillies
Modified: 2016-04-18 06:55 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-30 14:06:24 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 251291 0 None MERGED Passes to os-cloud-config Keystone{Admin,Internal}Vip 2020-10-21 19:13:53 UTC

Description Graeme Gillies 2015-11-27 06:15:16 UTC
Hi,

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 |            http://10.8.188.11:8777/           |            http://172.16.104.12:8777/           |         http://172.16.104.12:8777/         | f7f55e73fb974af3990098986b7db15f |   
| 570dbad946a74035a56ceeeb5ef8f180 | regionOne |    http://10.8.188.11:8774/v2/$(tenant_id)s   |    http://172.16.104.12:8774/v2/$(tenant_id)s   | http://172.16.104.12:8774/v2/$(tenant_id)s | cdfe2ad5bb204a60aa69f97903c1f1eb |   
| 88dc1c8d3d1b4daca57c3d0a70378190 | regionOne |            http://10.8.188.11:9292/           |            http://172.16.103.11:9292/           |         http://172.16.103.11:9292/         | 81744cf6ce434182b03ac516e6563e02 |   
| a533dc1f6c4d4d36a42c55038898e3bc | regionOne | http://10.8.188.11:8080/v1/AUTH_%(tenant_id)s | http://172.16.103.11:8080/v1/AUTH_%(tenant_id)s |        http://172.16.103.11:8080/v1        | e49b26683a634ae6a5ca622d6f0db2e6 |   
| b64a025e6e5a4d2b8f4202896724f472 | regionOne |    http://10.8.188.11:8776/v1/%(tenant_id)s   |    http://172.16.104.12:8776/v1/%(tenant_id)s   | http://172.16.104.12:8776/v1/%(tenant_id)s | 211b1bb1559a40b3bc475e46f8e9c531 |   
| b94fbfbe5f784623b2402ef390674391 | regionOne |          http://10.8.188.11:5000/v2.0         |           http://10.8.188.11:5000/v2.0          |       http://10.8.188.11:35357/v2.0        | e3c894a60d21403b82c78268d41d8cff |   
| c340f5a2bf884627abc894ba31099841 | regionOne |    http://10.8.188.11:8776/v2/%(tenant_id)s   |    http://172.16.104.12:8776/v2/%(tenant_id)s   | http://172.16.104.12:8776/v2/%(tenant_id)s | adc6567cede6461e8ca0418c99e4a1ee |   
| d0c1411a318347a4882709d599fb985a | regionOne |    http://10.8.188.11:8004/v1/%(tenant_id)s   |    http://172.16.104.12:8004/v1/%(tenant_id)s   | http://172.16.104.12:8004/v1/%(tenant_id)s | ebe025895e794720bcdf6a29048087bb |   
| d4583cf26d6747b7a332bed761c85964 | regionOne |           http://10.8.188.11:8774/v3          |           http://172.16.104.12:8774/v3          |        http://172.16.104.12:8774/v3        | 8729da0d78fe41b7a6374b6473cb3ac7 |   
| e916d499f0224b36abd1490307c00882 | regionOne |        http://10.8.188.11:80/dashboard/       |         http://10.8.188.11:80/dashboard/        |   http://10.8.188.11:80/dashboard/admin    | 556c495592684eb4ab0d68c313765f88 |   
| f66092989a8b4918b029cbcb130436ff | regionOne |            http://10.8.188.11:9696/           |            http://172.16.104.12:9696/           |         http://172.16.104.12:9696/         | 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

        keystone.initialize(
            keystone_ip,
            passwords['OVERCLOUD_ADMIN_TOKEN'],
            'admin',
            passwords['OVERCLOUD_ADMIN_PASSWORD'],
            public=overcloud_ip,
            user='heat-admin')

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.

Regards,

Graeme

Comment 2 Giulio Fidente 2015-11-27 09:14:17 UTC
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 09:18:10 UTC
(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

  ServiceNetMap:
      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

Regards,

Graeme

Comment 4 Mike Burns 2015-11-30 14:06:24 UTC

*** 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.