<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 10:00 AM, Simon Pasquier <span dir="ltr"><<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>First of all, I'm +1 on this. But as Matt says, it needs to take care of the plugins.<br>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?<br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>-Alex</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Simon<br><div><br>[1] <a href="https://github.com/openstack/fuel-plugin-external-zabbix/blob/2.5.0/deployment_scripts/puppet/modules/plugin_zabbix/manifests/ha/haproxy.pp#L16" target="_blank">https://github.com/openstack/fuel-plugin-external-zabbix/blob/2.5.0/deployment_scripts/puppet/modules/plugin_zabbix/manifests/ha/haproxy.pp#L16</a><br>[2] <a href="https://github.com/openstack/fuel-plugin-lma-collector/blob/master/deployment_scripts/puppet/manifests/aggregator.pp#L60-L81" target="_blank">https://github.com/openstack/fuel-plugin-lma-collector/blob/master/deployment_scripts/puppet/manifests/aggregator.pp#L60-L81</a><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 4:42 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@mirantis.com" target="_blank">aschultz@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, May 12, 2016 at 8:39 AM, Matthew Mosesohn <span dir="ltr"><<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Alex,<br>
<br>
Collapsing our haproxy tasks makes it a bit trickier for plugin<br>
developers. We would still be able to control it via hiera, but it<br>
means more effort for a plugin developer to run haproxy for a given<br>
set of services, but explicitly exclude all those it doesn't intend to<br>
run on a custom role. Maybe you can think of some intermediate step<br>
that wouldn't add a burden to a plugin developer that would want to<br>
just proxy keystone and mysql, but not nova/neutron/glance/cinder?<br>
<div><div><br></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>-Alex</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/307538/9/deployment/puppet/osnailyfacter/modular/cluster-haproxy/cluster-haproxy.pp" target="_blank">https://review.openstack.org/#/c/307538/9/deployment/puppet/osnailyfacter/modular/cluster-haproxy/cluster-haproxy.pp</a></div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div>
On Thu, May 12, 2016 at 5:34 PM, Alex Schultz <<a href="mailto:aschultz@mirantis.com" target="_blank">aschultz@mirantis.com</a>> wrote:<br>
> Hey Fuelers,<br>
><br>
> We have been using our own fork of the haproxy module within fuel-library<br>
> for some time. This also includes relying on a MOS specific version of<br>
> haproxy that carries the conf.d hack.  Unfortunately this has meant that<br>
> we've needed to leverage the MOS version of this package when deploying with<br>
> UCA.  As far as I can tell, there is no actual need to continue to do this<br>
> anymore. I have been working on switching to the upstream haproxy module[0]<br>
> so we can drop this custom haproxy package and leverage the upstream haproxy<br>
> module.<br>
><br>
> In order to properly switch to the upstream haproxy module, we need to<br>
> collapse the haproxy tasks into a single task. With the migration to<br>
> leveraging classes for task functionality, this is pretty straight forward.<br>
> In my review I have left the old tasks still in place to make sure to not<br>
> break any previous dependencies but they old tasks no longer do anything.<br>
> The next step after this initial merge would be to cleanup the haproxy code<br>
> and extract it from the old openstack module.<br>
><br>
> Please be aware that if you were relying on the conf.d method of injecting<br>
> configurations for haproxy, this will break you. Please speak up now so we<br>
> can figure out an alternative solution.<br>
><br>
> Thanks,<br>
> -Alex<br>
><br>
><br>
> [0] <a href="https://review.openstack.org/#/c/307538/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/307538/</a><br>
><br>
</div></div>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>