Open Stack

> 1 and 2 -> Create an httpd::mod defined type that is a wrapper of the original httpd_mod, as done on https://review.openstack.org/#/c/216835/. This wrapper should add the before (and notify?) calls ,
> as well as skipping the call to httpd_mod in centos case (https://review.openstack.org/#/c/216318/) <https://review.openstack.org/#/c/216318/%29>. This is a good solution, but will involve a rewrite on all our manifests, to replace httpd_mod
> calls by httpd::mod as done on https://review.openstack.org/#/c/217334/.

I think that is a good solution as it will remove a lot of duplicate code in others manifests. Also modifying the others manifests can be done smoothly
as http_mod and the new resource http::mod will coexist together. Furthermore as well as handling there the race and the centos support I'm wondering if
we can introduce into http::mod this kind of check: "if ! defined(Httpd::Mod['themod']) {httpd::mod { 'themod': ensure => present}}" ?

Thanks for raising this discussion on the ml.

Fabien

On 28/08/2015 07:45, Yolanda Robla Mota wrote:
> So ... to summarize, we found 3 different issues:
> 
> 1. Races on httpd_mod -> httpd_mod is a custom type, relying on ruby code. It has a clear race, that is shown on all of our manifests using that. If you use httpd_mod to install
> new apache modules, they won't be applied until apache is restarted manually. Reason is that the manifest installs the apache package, and just after that does a start of the apache service,
> without considering other extra configurations needed (httpd_mod in that case).
> 
> 2. httpd_mod is not valid for Centos/RHEL systems. There is a change proposed to fix this behaviour in internal types: https://review.openstack.org/#/c/216318/
> But really all our manifests using httpd_mod should be applying this patch as well. Also, manual workarounds are needed to install mods on CentOS:
>     https://review.openstack.org/#/c/199798/8/manifests/init.pp
>     
> puppetlabs-apache does the job internally, allowing to pass related packages to the apache::mod
> construction: https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/mod.pp
> 
> 3. Module does not offer possibilities for adding extra configuration files, need to be done manually such as on: https://review.openstack.org/#/c/215169/2/manifests/apache.pp
> puppetlabs-apache module is offering that: https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/custom_config.pp
> 
> And the short term solution for each problem will be:
> 
> 1 and 2 -> Create an httpd::mod defined type that is a wrapper of the original httpd_mod, as done on https://review.openstack.org/#/c/216835/. This wrapper should add the before (and notify?) calls ,
> as well as skipping the call to httpd_mod in centos case (https://review.openstack.org/#/c/216318/) <https://review.openstack.org/#/c/216318/%29>. This is a good solution, but will involve a rewrite on all our manifests, to replace httpd_mod
> calls by httpd::mod as done on https://review.openstack.org/#/c/217334/.
> 
> 3 -> we should take a look at https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/custom_config.pp , get inspired by that, and add this bits to our httpd module.
> 
> In the long term i'm in favour for puppetlabs-apache migration, but that can be an independent discussion.
> 
> Do we agree on this plan?
> 
> Best
> Yolanda
> 
> 
> El 28/08/15 a las 03:08, Jeremy Stanley escribió:
>> On Thu, Aug 27, 2015 at 5:38 PM, Spencer Krum <krum.spencer at gmail.com> wrote:
>> [...]
>>> In that case I would recommend either before => Package['httpd'] or before
>>> => Class['httpd::install']. (The second one requires us to create that
>>> class, but this is a pattern used by many modules to expose exactly this
>>> kind of hooks into the dependency graph).
>> Do you maybe mean "after => Package['httpd']" there? The directories
>> we want to put these files in won't exist until the package
>> installation completes. We just want to make sure we notify the
>> service after the files get installed.
>>
>> Anyway, I'm willing to give this another shot. I will admit I took
>> the easy way out in my patch and just puppeted the needed
>> directories after I ran up against Puppet complaining about a
>> circular dep tree calculation.
> 
> -- 
> Yolanda Robla Mota
> Cloud Automation and Distribution Engineer
> +34 605641639
> yolanda.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
>