Open Stack

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 
> <yolanda.robla-mota at hp.com <mailto:yolanda.robla-mota at hp.com>> 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
>>     <yolanda.robla-mota at hp.com <mailto:yolanda.robla-mota at 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 at lists.openstack.org  <mailto:OpenStack-Infra at 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-mota at hp.com  <mailto:yolanda.robla-mota at hp.com>
>>
>>
>>         _______________________________________________
>>         OpenStack-Infra mailing list
>>         OpenStack-Infra at lists.openstack.org
>>         <mailto:OpenStack-Infra at 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-mota at hp.com  <mailto:yolanda.robla-mota at hp.com>
>
>
>     _______________________________________________
>     OpenStack-Infra mailing list
>     OpenStack-Infra at lists.openstack.org
>     <mailto:OpenStack-Infra at lists.openstack.org>
>     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
yolanda.robla-mota at hp.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150827/d4a138a0/attachment-0001.html>