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] 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
