Re: [openstack-dev] [fuel] switch to upstream haproxy module

On Thu, May 12, 2016 at 6:13 PM, Alex Schultz wrote: > > > On Thu, May 12, 2016 at 10:00 AM, Simon Pasquier > wrote: > >> First of all, I'm +1 on this. But as Matt says, it needs to take care of >> the plugins. >> A few examples I know of are the

Re: [openstack-dev] [fuel] switch to upstream haproxy module

On Thu, May 12, 2016 at 10:00 AM, Simon Pasquier wrote: > First of all, I'm +1 on this. But as Matt says, it needs to take care of > the plugins. > A few examples I know of are the Zabbix plugin [1] and the LMA collector > plugin [2] that modify the HAProxy configuration

Re: [openstack-dev] [fuel] switch to upstream haproxy module

First of all, I'm +1 on this. But as Matt says, it needs to take care of the plugins. A few examples I know of are the Zabbix plugin [1] and the LMA collector plugin [2] that modify the HAProxy configuration of the controller nodes. How could they work with your patch? Simon [1]

Re: [openstack-dev] [fuel] switch to upstream haproxy module

On Thu, May 12, 2016 at 8:39 AM, Matthew Mosesohn wrote: > Hi Alex, > > Collapsing our haproxy tasks makes it a bit trickier for plugin > developers. We would still be able to control it via hiera, but it > means more effort for a plugin developer to run haproxy for a

[openstack-dev] [fuel] switch to upstream haproxy module

Hey Fuelers, We have been using our own fork of the haproxy module within fuel-library for some time. This also includes relying on a MOS specific version of haproxy that carries the conf.d hack. Unfortunately this has meant that we've needed to leverage the MOS version of this package when

Re: [openstack-dev] [fuel] switch to upstream haproxy module

Hi Alex, Collapsing our haproxy tasks makes it a bit trickier for plugin developers. We would still be able to control it via hiera, but it means more effort for a plugin developer to run haproxy for a given set of services, but explicitly exclude all those it doesn't intend to run on a custom