<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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 class="h5"><br></div></div></blockquote><div><br></div><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">https://review.openstack.org/#/c/307538/9/deployment/puppet/osnailyfacter/modular/cluster-haproxy/cluster-haproxy.pp</a></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 class="h5">
On Thu, May 12, 2016 at 5:34 PM, Alex Schultz <<a href="mailto:aschultz@mirantis.com">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><br></div></div>