Open Stack

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> 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>:
>
>> 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
>>
>>
>> _______________________________________________
>> OpenStack-Infra mailing listOpenStack-Infra at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>> --
>> Yolanda Robla Mota
>> Cloud Automation and Distribution Engineer+34 605641639yolanda.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
>>
>>
>
> --
> Yolanda Robla Mota
> Cloud Automation and Distribution Engineer+34 605641639yolanda.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
>
>


-- 
Spencer Krum
(619)-980-7820
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150827/1acf5dc7/attachment.html>