[OpenStack-Infra] Puppet Apache Dependency Issues

Paul Belanger pabelanger at redhat.com
Fri Aug 28 00:42:25 UTC 2015


On Wed, Aug 26, 2015 at 11:31:35AM -0700, Spencer Krum wrote:
> 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.
> 
For me, migrating to puppet-apache is a long term goal. I personally would like
to see us do it but know it will take us work to get there.  So, to fix the
ordering issue, which ever way falls inline more with upstream puppet-apache
gets my vote.  I would be reluctant to have us implement our own solution,
where (correct me if I am wrong) this works properly under puppet-apache.

So, I would like to see option 3, since upstream does this.

> 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 list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra




More information about the OpenStack-Infra mailing list