I agree with Colleen and Clark that option #1 is the best. -- Spencer Krum n...@spencerkrum.com
On Thu, Nov 5, 2015, at 02:33 PM, Clark Boylan wrote: > 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 _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
