> 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 <[email protected]> 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
> [email protected]
>
>
>
> _______________________________________________
> OpenStack-Infra mailing list
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
