+ 1 -Bryan
> On Mar 14, 2019, at 11:26 AM, Leif Hedstrom <zw...@apache.org> wrote: > > Hi all, > > As we’re making more progress migrating towards YAML configurations, I’d like > to make two proposals for v9.0.0: > > > 1) As we migrate a configuration to the new YAML format, we only support > YAML. I.e. no backwards compatibility layers. Of course, we only break such > compatibility in major versions, which is also why we want to get as much of > this in before 9.0.0 as possible. > > 2) We remove the following configurations from records.config, and only > support the default config files names (e.g. ip_allow.yaml). > > proxy.config.cache.storage_filename > proxy.config.cache.control.filename > proxy.config.cache.ip_allow.filename > proxy.config.cache.hosting_filename > proxy.config.cache.volume_filename > proxy.config.dns.splitdns.filename > proxy.config.log.config.filename > proxy.config.url_remap.filename > > > Some justifications: > > For 1; We will name the new configs .yaml, e.g. ip_allow.yaml, which allows > everyone to keep the old .config file (e.g. ip_allow.config), such that you > can downgrade the ATS binaries, and keep the configuration tree. > > For 1; A big reason for the migration to the new YAML is that we can add new > features here in a much more reasonable way. Trying to maintain both the old > and the new configuration formats puts an unreasonable burden on development. > It also makes for a less friendly UX IMO, where if you stick to the old > version of the configurations, you won’t be able to use the same features as > if you pick the YAML format. > > For 2: These configurations were just kinda useless to begin with, and with > YAML, and the organization of YAML configs into name spaces, we can move > towards a single configuration file / format approach (with #include and > config.d/ directories). These old configurations do not play well with this > goal. > > > If there are concerns about any of these, please voice them here. I imagine > the most controversial is 1) above, so if you feel strongly here, be prepared > to back this with valid arguments, and development resources :-). > > Cheers, > > — Leif >
