On Thu, Nov 5, 2015, at 01:05 PM, Colleen Murphy wrote: > On Wed, Nov 4, 2015 at 10:55 AM, Yolanda Robla Mota < > yolanda.robla-m...@hpe.com> wrote: > > > Hello Infra > > > > I want to start a thread about the best way to reconcile the apache fixes > > that we put on place for upgrade to apache >= 2.4 > > The are two different ways now: > > > > 1. rely on apache mod_version , and add a check inside apache vhosts: > > > > <IfVersion >= 2.4> > > Require all granted > > </IfVersion> > > > > That is the fix currently on place for puppet-httpd, puppet-cgit, and some > > other modules. It is quite simple, but has the disadvantage of depending on > > mod_version apache module, so every manifest using that needs to ensure > > that mod_version is installed. > > > > 2. Rely on satisfy any: > > > > Allow from all > > Satisfy Any > > > > It doesn't need an extra check for version, but it is deprecated as shown > > on: https://httpd.apache.org/docs/2.4/howto/auth.html . It also needs > > module mod_access_compat to be present > > in newer apache versions. We currently have this on puppet-zuul. > > > > 3. Another alternatives should be: > > - add a parameter to puppet-httpd module, so we can pass the apache > > version we are expected to have > > - create a custom fact to give us the current apache version in puppet, > > and do the apache check using that fact instead of relying in mod_version > > - use osfamily/operatingsystem/lsbrelease facts to decide about apache > > version, and apply proper directives there > > > > I'd like to get more opinions about how to better proceed with that, and > > ensure that all infra puppet modules are following the same criteria. > > > > Best > > > > I kind of like the idea of offloading this kind of logic into the service > and out of config management, especially since mod_version makes it easy > to > do so. If on some terrible day we decide to switch config management > tools, > this kind of mindset will make the switchover a tiny bit easier. So I'm a > fan of option 1. I don't know enough about Apache to comment on option 2. > Options in 3 are more puppetty but I don't see a big advantage to any of > them. ++ Option 1 makes it easier for others to learn from and reuse our apache configs as well. Option 2 would be fine if that was the only place we run into version compatibility problems but we have run into other cases (with zuul status.json caching) so using a more generic version switch is my preference.
Clark _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
