On Thu, May 12, 2016 at 6:13 PM, Alex Schultz <aschu...@mirantis.com> wrote:
> > > On Thu, May 12, 2016 at 10:00 AM, Simon Pasquier <spasqu...@mirantis.com> > 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 of the controller nodes. >> How could they work with your patch? >> > > So you are leveraging the haproxy on the controller for this > configuration? I thought I had asked in irc about this and was under the > impression that you're using your own haproxy configuration on a different > host(s). I'll have to figure out an alternative to support plugin haproxy > configurations as with that patch it would just ignore those configurations. > For other plugins, we use dedicated HAProxy nodes but not for these 2 (at least). I admit that it wasn't a very good idea but at that time, it was "oh perfect, /etc/haproxy/conf.d is there, let's use it!". We'll try to think about a solution on our end too. Simon > > Thanks, > -Alex > > >> Simon >> >> [1] >> https://github.com/openstack/fuel-plugin-external-zabbix/blob/2.5.0/deployment_scripts/puppet/modules/plugin_zabbix/manifests/ha/haproxy.pp#L16 >> [2] >> https://github.com/openstack/fuel-plugin-lma-collector/blob/master/deployment_scripts/puppet/manifests/aggregator.pp#L60-L81 >> >> On Thu, May 12, 2016 at 4:42 PM, Alex Schultz <aschu...@mirantis.com> >> wrote: >> >>> >>> >>> On Thu, May 12, 2016 at 8:39 AM, Matthew Mosesohn < >>> mmoses...@mirantis.com> 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 given >>>> set of services, but explicitly exclude all those it doesn't intend to >>>> run on a custom role. Maybe you can think of some intermediate step >>>> that wouldn't add a burden to a plugin developer that would want to >>>> just proxy keystone and mysql, but not nova/neutron/glance/cinder? >>>> >>>> >>> So none of the existing logic has changed around the enabling/disabling >>> of those tasks within hiera. The logic remains the same as I'm just >>> including the osnailyfacter::openstack_haproxy::openstack_haproxy_* >>> classes[0] within the haproxy task. The only difference is that the task >>> logic no longer would control if something was included like sahara. >>> >>> -Alex >>> >>> [0] >>> https://review.openstack.org/#/c/307538/9/deployment/puppet/osnailyfacter/modular/cluster-haproxy/cluster-haproxy.pp >>> >>> >>>> On Thu, May 12, 2016 at 5:34 PM, Alex Schultz <aschu...@mirantis.com> >>>> wrote: >>>> > 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 >>>> deploying with >>>> > UCA. As far as I can tell, there is no actual need to continue to do >>>> this >>>> > anymore. I have been working on switching to the upstream haproxy >>>> module[0] >>>> > so we can drop this custom haproxy package and leverage the upstream >>>> haproxy >>>> > module. >>>> > >>>> > In order to properly switch to the upstream haproxy module, we need to >>>> > collapse the haproxy tasks into a single task. With the migration to >>>> > leveraging classes for task functionality, this is pretty straight >>>> forward. >>>> > In my review I have left the old tasks still in place to make sure to >>>> not >>>> > break any previous dependencies but they old tasks no longer do >>>> anything. >>>> > The next step after this initial merge would be to cleanup the >>>> haproxy code >>>> > and extract it from the old openstack module. >>>> > >>>> > Please be aware that if you were relying on the conf.d method of >>>> injecting >>>> > configurations for haproxy, this will break you. Please speak up now >>>> so we >>>> > can figure out an alternative solution. >>>> > >>>> > Thanks, >>>> > -Alex >>>> > >>>> > >>>> > [0] https://review.openstack.org/#/c/307538/ >>>> > >>>> > >>>> __________________________________________________________________________ >>>> > OpenStack Development Mailing List (not for usage questions) >>>> > Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
