I agree with that approach. We are hitting several issues with httpd_mod
that should be fixed using a defined type.
But I do believe that the way is to consume modules that are trusted by
the community, and don't put efforts on maintaining and evolving our own
modules if there are good alternatives. This will need a patch to
puppetlabs-apache or a wrapper, and a proper migration plan, so it needs
an spec.
Best
Yolanda
El 27/08/15 a las 11:23, Ricardo Carrillo Cruz escribió:
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-m...@hp.com <mailto:yolanda.robla-m...@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 <tel:%28619%29-980-7820>
_______________________________________________
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
<mailto:OpenStack-Infra@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639 <tel:%2B34%20605641639>
yolanda.robla-m...@hp.com <mailto:yolanda.robla-m...@hp.com>
_______________________________________________
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
<mailto:OpenStack-Infra@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hp.com
_______________________________________________
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
