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
