[OpenStack-Infra] Puppet Apache Dependency Issues

Ricardo Carrillo Cruz ricardo.carrillo.cruz at gmail.com
Thu Aug 27 09:23:40 UTC 2015


I lean towards fixing now by using the new defined type and we write a spec
for migrating to puppetlabs-apache (once we merge in upstream infra needs).

Regards

2015-08-27 11:07 GMT+02:00 Yolanda Robla Mota <yolanda.robla-mota at hp.com>:

> Hi
> Thanks for the explanation. As this is a topic that needs more background,
> and a deeper discussion, I created an etherpad to work on it.
> You can access on:
> https://etherpad.openstack.org/p/puppet-httpd_vs_puppetlabs-apache
>
> Best
> Yolanda
>
> El 26/08/15 a las 20:31, Spencer Krum escribió:
>
> Hello All,
>
> At the meeting on August 25th, we discussed an issue with the puppet-httpd
> module and a few solutions. The issue is that the httpd_mod type does not
> have a baked-in ordering relationship with the Service['httpd'] resource.
> This means that sometimes httpd_mod resources are instantiated after the
> service attempts to come up, meaning the service cannot start.
>
> A few solutions have been proposed:
>
> 1) Modify our use of the httpd_mod resource to use 'before' everywhere.
> This patch [1] is an example of doing that for puppet-gerrit, we'd have to
> perform similar modifications elsewhere in our code.
>
> 2) Modify the httpd module to do this automatically. This patch [2]
> changes the type at the ruby layer using puppet internal apis to add an
> 'autobefore' on the Service['httpd'] resource.
>
> 3) Create an httpd::mod defined type that can do this automatically. We'd
> have to then change every invocation of httpd_mod to be httpd::mod. This
> patch [3] is the patch to create httpd::mod and this patch [4] shows what
> using it would be like. We'd have to apply changes like [4] everywhere in
> our infrastructure.
>
> 4) Migrate to puppetlabs-apache. This has two forms, one(4a) involving
> patching that module to support our usecase and the other(4b) where we use
> the existing api.
>
> I have my own opinions about what we should be doing, but this message is
> meant to explain the problem and roads available to us, not to editorialize.
>
> [1] https://review.openstack.org/#/c/216708/
> [2] https://review.openstack.org/#/c/216436/
> [3] https://review.openstack.org/#/c/216835/
> [4] https://review.openstack.org/#/c/217334/
>
> --
> Spencer Krum
> (619)-980-7820
>
>
> _______________________________________________
> OpenStack-Infra mailing listOpenStack-Infra at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
> --
> Yolanda Robla Mota
> Cloud Automation and Distribution Engineer+34 605641639yolanda.robla-mota at hp.com
>
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150827/3b43b2c0/attachment.html>


More information about the OpenStack-Infra mailing list