Open Stack

On Thu, May 12, 2016 at 6:13 PM, Alex Schultz <aschultz at mirantis.com> wrote:

>
>
> On Thu, May 12, 2016 at 10:00 AM, Simon Pasquier <spasquier at 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 <aschultz at mirantis.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, May 12, 2016 at 8:39 AM, Matthew Mosesohn <
>>> mmosesohn at 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 <aschultz at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160512/d68b9016/attachment.html>