Hide Forgot
Description of problem: When deploying using network isolation, the ceph, cinder, and swift nodes were getting a bridge name of "br-ex". Since this bridge isn't carrying any external traffic, that doesn't make sense. It should be br-storage. Version-Release number of selected component (if applicable): All poodles and puddles prior to Jun 16, 2015. How reproducible: 100% Steps to Reproduce: 1. Deploy overcloud with network isolation using bond-with-vlans or single-nic-vlans templates. 2. 3. Actual results: Storage nodes have a "br-ex" bridge. Expected results: Storage nodes should have a "br-storage" bridge. Additional info: You can check the Heat templates network/config/single-nic-vlans and network/config/bond-with-vlans to see that the storage templates have been updated with "br-storage".
rpm -qa |grep openstack-tripleo-heat-templates openstack-tripleo-heat-templates-0.8.6-44.el7ost.noarch looking in the undercloud node from /home/stack/nic-configs/ceph-storage.yaml resources: OsNetConfigImpl: type: OS::Heat::StructuredConfig properties: group: os-apply-config config: os_net_config: network_config: - type: ovs_bridge name: br-storage use_dhcp: true from /home/stack/nic-configs/cinder-storage.yaml resources: OsNetConfigImpl: type: OS::Heat::StructuredConfig properties: group: os-apply-config config: os_net_config: network_config: - type: ovs_bridge name: br-storage use_dhcp: true from /home/stack/nic-configs/swift-storage.yaml resources: OsNetConfigImpl: type: OS::Heat::StructuredConfig properties: group: os-apply-config config: os_net_config: network_config: - type: ovs_bridge name: br-storage use_dhcp: true [heat-admin@overcloud-compute-0 ~]$ sudo ovs-vsctl show 4244091b-03c1-4932-b963-ed5bfbad9f7f Bridge br-int fail_mode: secure Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port br-int Interface br-int type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Bridge br-vlan Port "vlan185" tag: 185 Interface "vlan185" type: internal Port "em2" Interface "em2" Port br-vlan Interface br-vlan type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Bridge br-tun fail_mode: secure Port br-tun Interface br-tun type: internal Port "vxlan-c0a8640d" Interface "vxlan-c0a8640d" type: vxlan options: {df_default="true", in_key=flow, local_ip="192.168.100.10", out_key=flow, remote_ip="192.168.100.13"} Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "vxlan-c0a8640b" Interface "vxlan-c0a8640b" type: vxlan options: {df_default="true", in_key=flow, local_ip="192.168.100.10", out_key=flow, remote_ip="192.168.100.11"} Port "vxlan-c0a8640c" Interface "vxlan-c0a8640c" type: vxlan options: {df_default="true", in_key=flow, local_ip="192.168.100.10", out_key=flow, remote_ip="192.168.100.12"} ovs_version: "2.3.1-git3282e51" [heat-admin@overcloud-compute-0 ~]$
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