Bug 1244032

(In reply to John Fulton from comment #0)
> Can OSP-Director deploy an overcloud with an HA control plane which uses a
> hardware load balancer in place of HAproxy? 

This isn't supported today but it should be possible to put in conditionals to allow such a configuration.

I think we should be able to take an approach similar to what we did w/ external Ceph support and allow the required parameters to be passed into Heat (probably via nested stack parameters, in a parameter_defaults section somewhere). This would allow us to wire up the provided VIPs and conditionally disable the installation of managed load balancer components.

There may be a few puppet pacemaker changes required (not sure yet) but again we think those should be doable. Still some details with regards to pacemakers integration with the LB that need to be reviewed but we think it is possible.

We might put some thought into validating the settings of the hardware loadbalancer early on in our installer so that confusing failures don't happen later. Perhaps this can be a custom validation script that lives in the same nested Heat stack or is otherwise enabled when using an external hardware LB. It would for example be nice to know that specific ports for things like MySQL and Rabbit are configured properly early on... otherwise a slew of installer failures would likely happen later on and perhaps confuse the root cause of any load balancer configuration issues.

> 
> Desired features:
> - If the hardware load balancer were set up before the overcloud was
> deployed, then could the properties of that load balancer be provided to
> OSP-Director (e.g. in a yaml file) so that overcloud used the hardware load
> balancer automatically after deployment? 
> - Can this feature support hardware more than one load balancer configured
> in round robin per overcloud?

Created attachment 1078815 [details]
haproxy config

This got me a successful deployment, tested with an external haproxy. Attaching the haproxy config.

openstack overcloud deploy --templates ~/templates/my-overcloud -e ~/templates/my-overcloud/environments/network-isolation.yaml -e ~/templates/network-environment.yaml --control-scale 3 --compute-scale 1 --ceph-storage-scale 3  --ntp-server 10.5.26.10 --libvirt-type qemu -e /usr/share/openstack-tripleo-heat-templates/environments/external-loadbalancer-vip.yaml -e ~/templates/external-lb.yaml -e ~/templates/ceph.yaml

cat ~/templates/external-lb.yaml 
parameters:
  ServiceNetMap:
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    MongoDbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: storage
    GlanceRegistryNetwork: internal_api
    KeystoneAdminApiNetwork: internal_api
    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

parameter_defaults:
  ControlPlaneIP: 192.0.2.250
  ExternalNetworkVip: 172.16.23.250
  InternalApiNetworkVip: 172.16.20.250
  StorageNetworkVip: 172.16.21.250
  StorageMgmtNetworkVip: 172.16.19.250
  ServiceVips:
    redis: 172.16.20.249
  ControllerIPs:
    external:
    - 172.16.23.150
    - 172.16.23.151
    - 172.16.23.152
    internal_api:
    - 172.16.20.150
    - 172.16.20.151
    - 172.16.20.152
    storage:
    - 172.16.21.150
    - 172.16.21.151
    - 172.16.21.152
    storage_mgmt:
    - 172.16.19.150
    - 172.16.19.151
    - 172.16.19.152
    tenant:
    - 172.16.22.150
    - 172.16.22.151
    - 172.16.22.152
    external_cidr: "24"
    internal_api_cidr: "24"
    storage_cidr: "24"
    storage_mgmt_cidr: "24"
    tenant_cidr: "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/RHSA-2015:1862