Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160512/c44baf26/attachment.html>