So... we are already consuming several modules from other providers,
relying on it. Is there some problem of trust in the puppetlabs-apache
community?
Which are the main reasons (apart from the vhost generation) that are
preventing us to rely on it, while we rely on others?
El 27/08/15 a las 20:22, Spencer Krum escribió:
I don't think we should plan to use puppet-apache. I think we should
commit to our fork and fix the issues we have. We can build a simple,
flexible apache module and stop. Committing to puppetlabs-apache puts
us on the roller coaster of updates and bugfixes.
The issues we are having are not hard to fix, imho. As with any
software we build, we need to classify the problems, identify the
fixes, do the work, etc.
On Thu, Aug 27, 2015 at 11:09 AM, Yolanda Robla Mota
<[email protected] <mailto:[email protected]>> wrote:
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
<[email protected] <mailto:[email protected]>>:
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
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639 <tel:%2B34%20605641639>
[email protected] <mailto:[email protected]>
_______________________________________________
OpenStack-Infra mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639 <tel:%2B34%20605641639>
[email protected] <mailto:[email protected]>
_______________________________________________
OpenStack-Infra mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
--
Spencer Krum
(619)-980-7820
--
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
