Bug 1270910

Note that when passing /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml as environment file I got the IP set as expected:

openstack overcloud deploy --templates ~/templates/my-overcloud -e ~/templates/my-overcloud/environments/network-isolation.yaml -e ~/templates/network-environment.yaml --control-scale 1 --compute-scale 1 --libvirt-type qemu -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml

[stack@instack ~]$ ssh heat-admin.2.16 'sudo ip a s dev br-ex | grep inet'
    inet 192.0.2.16/24 brd 192.0.2.255 scope global br-ex
    inet 192.0.2.15/32 brd 192.0.2.255 scope global br-ex
    inet6 fe80::231:d1ff:fe11:6eb1/64 scope link 
[stack@instack ~]$ ssh heat-admin.2.16 'sudo ip a s dev vlan10 | grep inet'
    inet 172.16.23.11/24 brd 172.16.23.255 scope global vlan10
    inet 172.16.23.10/32 brd 172.16.23.255 scope global vlan10
    inet6 fe80::4c0f:deff:fe2b:d574/64 scope link

I'm not sure what is going on here. I just did a deployment over the weekend with the single-nic-with-vlans templates, and this didn't happen. I'm running it again just to be sure.

(In reply to Dan Sneddon from comment #2)
> I'm not sure what is going on here. I just did a deployment over the weekend
> with the single-nic-with-vlans templates, and this didn't happen. I'm
> running it again just to be sure.

Nevermind, I was not using the latest Liberty code. This is probably a new problem which has crept in upstream.

@Dan, is network isolation even supposed to work without pacemaker?

see comment 1: https://bugzilla.redhat.com/show_bug.cgi?id=1270910#c1

(In reply to John Trowbridge from comment #4)
> @Dan, is network isolation even supposed to work without pacemaker?
> 
> see comment 1: https://bugzilla.redhat.com/show_bug.cgi?id=1270910#c1

Sure, if you don't have HA then Pacemaker is not required. Network Isolation doesn't have any dependencies on Pacemaker. When you use "-e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml", here's what happens:

puppet-pacemaker.yaml:
  OS::TripleO::ControllerConfig: ../puppet/controller-config-pacemaker.yaml

controller-config-pacemaker.yaml:
(doesn't do much, except it includes overcloud_controller_pacemaker.pp:
        get_file: manifests/overcloud_controller_pacemaker.pp

So, the difference is probably in how overcloud_controller_pacemaker.pp instantiates the public VIP:

#######
      $public_vip = hiera('tripleo::loadbalancer::public_virtual_ip')
      if $public_vip and $public_vip != $control_vip {
        pacemaker::resource::ip { 'public_vip':
          ip_address => $public_vip,
        }
        pacemaker::constraint::base { 'public_vip-then-haproxy':
          constraint_type   => 'order',
          first_resource    => "ip-${public_vip}",
          second_resource   => 'haproxy-clone',
          first_action      => 'start',
          second_action     => 'start',
          constraint_params => 'kind=Optional',
          require => [Pacemaker::Resource::Service['haproxy'],
                      Pacemaker::Resource::Ip['public_vip']],
        }
        pacemaker::constraint::colocation { 'public_vip-with-haproxy':
          source  => "ip-${public_vip}",
          target  => 'haproxy-clone',
          score   => 'INFINITY',
          require => [Pacemaker::Resource::Service['haproxy'],
                      Pacemaker::Resource::Ip['public_vip']],
        }
      }
#######

In a non-HA environment, haproxy will bring up the VIP, due to the bind statements in /etc/haproxy.conf, for example:

[heat-admin@overcloud-controller-0 etc]$ sudo grep -r 10.0.0.4 /etc/*
/etc/dnsmasq.conf:# and this maps 192.168.0.10->192.168.0.40 to 10.0.0.10->10.0.0.40
grep: /etc/extlinux.conf: No such file or directory
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:8777 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:8776 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:9292 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:8004 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:8000 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:8003 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:80 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:35357 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:5000 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:9696 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:8773 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:6080 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:8774 
/etc/haproxy/haproxy.cfg:  bind 10.0.0.4:8080 
/etc/puppet/hieradata/vip_data.yaml:tripleo::loadbalancer::public_virtual_ip: 10.0.0.4

I haven't had a chance to test this on Liberty yet, so I'm not sure what is going on here. In older code, haproxy had those bind statements, and the VIP would come up automatically on the interface that matched the subnet. I can't imagine what we are doing in Liberty to cause that VIP to come up on the wrong interface.

Dan, Marius, in the non-HA scenario it is Keepalived bringing up the VIPs.

It requires us to pass an interface and we seem to be passing the correct variable, not sure abut its contents though, see [1].

Can you run the following two from a controller node:

sudo hiera tripleo::loadbalancer::control_virtual_interface
sudo hiera tripleo::loadbalancer::public_virtual_interface

1. https://github.com/openstack/puppet-tripleo/blob/master/manifests/loadbalancer.pp#L343

Hi Giulio, it seems that br-ex is used for both:
[heat-admin@overcloud-controller-0 ~]$ sudo hiera tripleo::loadbalancer::control_virtual_interface
br-ex
[heat-admin@overcloud-controller-0 ~]$ sudo hiera tripleo::loadbalancer::public_virtual_interface
br-ex

It looks like that is just a configurable value and it is coming from the PublicVirtualInterface parameter; defaults to br-ex.

Can you try passing the appropriate interface name with something like:

parameters:
  PublicVirtualInterface: vlan10

Works:

Added 'PublicVirtualInterface: vlan10' to parameter_defaults in network-environment.yaml and ran the deploy command:

[root@overcloud-controller-0 ~]# sudo hiera tripleo::loadbalancer::control_virtual_interface
br-ex
[root@overcloud-controller-0 ~]# sudo hiera tripleo::loadbalancer::public_virtual_interface
vlan10

This has been fixed - https://review.openstack.org/407196.