On 5/28/2015 2:54 PM, Jim Riggs wrote:
> Having to expend effort (e.g. re-design/update config and deployment)
to switch/update/upgrade to a new paradigm does not, IMO, mean that it's
not a solution for everyone. Anyone can take the time to implement and
automate the switch. Once that effort has been spent, you should have
nearly the same (maybe better) setup, with hopefully better security and
resource utilization in many cases. All of those php_admin_* directives
end up in a php-fpm conf file that can easily be automatically updated
and deployed.


Thinking about this more, what are the things preventing people from an
_easy_ upgrade path configuration-wise? A lot of this conversation
surrounded users and the impact of an upgrade to them. The interface for
the users' to the server is the configuration file. Maybe if we can
tackle that we can greatly reduce a barrier to upgrade (or maybe I'm too
optimistic)?

For the majority of my configs, it was the changes to the authorization
directives - it takes brainpower to figure out what AdminXYZ was trying
to do years ago and reflect that with the new directives. However, this
is deterministic... a perl script could do this work for me if I'd just
write it.

At $dayjob, this is the stuff I focus on. Tweaks to an existing script I
put together years ago to upgrade from 2.0 to 2.2 (or as Rich eloquently
put, "poop out" new configs) only required an hour's worth of work or so
to support upgrades from 2.2 to 2.4 minus the aforementioned authz
directives.

-- 
Daniel Ruggeri

Reply via email to