Open Stack

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-mota at 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