Description of problem: When deploying OSP 7 with network isolation, the public VIP ends up on the 'ctlplane' provisioning network instead of the external network. Version-Release number of selected component (if applicable): puddle-2015-06-24.1 How reproducible: 100% Steps to Reproduce: 1. Deploy OSP 7 with network isolation 2. 3. Actual results: Public services (public API, horizon) are listening on the provisioning network. Expected results: Public services should be listening on the external network. Additional info: I have submitted this patch upstream to address this issue: https://review.openstack.org/#/c/195328/
Verified the patch and the public VIP gets created on the external network: http://paste.openstack.org/show/321395/
verified on RHEL-OSP director puddle 7.0 RC puddle 2015-06-29-1 [stack@instack ~]$ rpm -qa |grep openstack-tripleo-heat-templates openstack-tripleo-heat-templates-0.8.6-22.el7ost.noarch stack@instack ~]$ source stackrc [stack@instack ~]$ neutron port-list +--------------------------------------+-------------------------------+-------------------+-----------------------------------------------------------------------------------+ | id | name | mac_address | fixed_ips | +--------------------------------------+-------------------------------+-------------------+-----------------------------------------------------------------------------------+ | 05070081-9b56-4cef-82c9-efcfd7e0b2ff | public_virtual_ip | fa:16:3e:b0:f4:da | {"subnet_id": "ddbc325d-2d96-4812-8e03-c9764c52c3e9", "ip_address": "10.0.0.4"} | | 0873faf2-4d44-40d9-9f1f-5fded6ab1428 | | 00:fa:f1:17:04:68 | {"subnet_id": "52b5cb2d-8622-4c44-9f43-8008105604d2", "ip_address": "192.0.2.12"} | | 08920bc4-bb03-4479-af73-5c7957400368 | | fa:16:3e:c9:65:89 | {"subnet_id": "4701ae4d-fa97-462c-ae2e-41020d452735", "ip_address": "172.16.2.6"} | | 145ddf60-0679-4fea-a437-fb47867f2e04 | | fa:16:3e:e4:c3:f8 | {"subnet_id": "52b5cb2d-8622-4c44-9f43-8008105604d2", "ip_address": "192.0.2.5"} | | 2cb64051-42b3-4952-993e-10e321cd0566 | | fa:16:3e:8d:6f:62 | {"subnet_id": "83dae208-a187-4487-b0db-d240727c1ee1", "ip_address": "172.16.1.5"} | | 3d3c75f6-6fd5-4fdb-84fa-ceddda1693b9 | | fa:16:3e:de:8c:e3 | {"subnet_id": "dfad350f-b9a2-4c2c-b39e-a982fef5fb3c", "ip_address": "172.16.0.4"} | | 5e961ee6-3287-41f0-b531-55157c7b2fb6 | internal_api_virtual_ip | fa:16:3e:3d:7d:40 | {"subnet_id": "4701ae4d-fa97-462c-ae2e-41020d452735", "ip_address": "172.16.2.4"} | | a4db7db3-6905-40b5-89f6-9c137cd1e289 | | fa:16:3e:05:61:d4 | {"subnet_id": "4701ae4d-fa97-462c-ae2e-41020d452735", "ip_address": "172.16.2.5"} | | a59b7620-2084-4edd-b05f-a612cab6ee88 | control_virtual_ip | fa:16:3e:a2:12:ba | {"subnet_id": "52b5cb2d-8622-4c44-9f43-8008105604d2", "ip_address": "192.0.2.10"} | | b5cdffce-0c1a-48f1-a87f-6cfef1d07f54 | | fa:16:3e:99:21:7b | {"subnet_id": "2d7b32a0-eeaa-471a-95fe-1dccdec3a30e", "ip_address": "172.16.3.5"} | | ba846c0f-c13a-4ab3-ada0-187c71e2af05 | storage_virtual_ip | fa:16:3e:ec:57:5f | {"subnet_id": "83dae208-a187-4487-b0db-d240727c1ee1", "ip_address": "172.16.1.4"} | | c5204542-4a51-4092-b0f7-86e413d931c3 | | 00:43:38:e0:93:9c | {"subnet_id": "52b5cb2d-8622-4c44-9f43-8008105604d2", "ip_address": "192.0.2.13"} | | c6d1564f-218d-465c-9e76-3060f10aaad0 | | fa:16:3e:fa:10:17 | {"subnet_id": "dfad350f-b9a2-4c2c-b39e-a982fef5fb3c", "ip_address": "172.16.0.5"} | | d22ce01e-65ca-49a4-ad99-071d7c99b10e | redis_virtual_ip | fa:16:3e:4c:95:9a | {"subnet_id": "52b5cb2d-8622-4c44-9f43-8008105604d2", "ip_address": "192.0.2.11"} | | e4222f56-7a4d-4086-ad6b-f0210074b78b | storage_management_virtual_ip | fa:16:3e:e0:08:90 | {"subnet_id": "2d7b32a0-eeaa-471a-95fe-1dccdec3a30e", "ip_address": "172.16.3.4"} | | f8ed96e0-6f8b-402c-aa48-20668fb34a3f | | fa:16:3e:6f:bf:59 | {"subnet_id": "ddbc325d-2d96-4812-8e03-c9764c52c3e9", "ip_address": "10.0.0.5"} | | fbba3fa6-0892-461c-a7a0-c60fac739c21 | | fa:16:3e:6f:9c:af | {"subnet_id": "83dae208-a187-4487-b0db-d240727c1ee1", "ip_address": "172.16.1.6"} | +--------------------------------------+-------------------------------+-------------------+-----------------------------------------------------------------------------------+ [stack@instack ~]$ neutron net-list +--------------------------------------+--------------+----------------------------------------------------+ | id | name | subnets | +--------------------------------------+--------------+----------------------------------------------------+ | 0f8471fc-e965-4003-8c32-a0d32ae29f07 | ctlplane | 52b5cb2d-8622-4c44-9f43-8008105604d2 192.0.2.0/24 | | 3813dd81-d484-4536-9d3d-7e7aeadd01ad | storage | 83dae208-a187-4487-b0db-d240727c1ee1 172.16.1.0/24 | | 53a565c8-22d7-4536-b436-bf14f089feef | external | ddbc325d-2d96-4812-8e03-c9764c52c3e9 10.0.0.0/24 | | 7cdf6723-117e-432a-a769-ba61b83eabe3 | internal_api | 4701ae4d-fa97-462c-ae2e-41020d452735 172.16.2.0/24 | | 98161cfa-26aa-4e02-89f1-12b7b2be5d80 | storage_mgmt | 2d7b32a0-eeaa-471a-95fe-1dccdec3a30e 172.16.3.0/24 | | fa4147fa-7d69-4184-92b4-d75bc7752108 | tenant | dfad350f-b9a2-4c2c-b39e-a982fef5fb3c 172.16.0.0/24 | +--------------------------------------+--------------+----------------------------------------------------+
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2015:1549