Open Stack

I agree with Colleen and Clark that option #1 is the best.

-- 
  Spencer Krum
  nibz at 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-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
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra