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 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 >> 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 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 usag
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 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. 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 > wrote: > >> >> >> 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 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 >>> 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 > > ___
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] 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 wrote: > > > 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 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 >> 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
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 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 > 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-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 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
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 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? On Thu, May 12, 2016 at 5:34 PM, Alex Schultz 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
