> > 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
Is "proxy.config.ssl.server.multicert.filename" also included? It will be ssl_multicert.yaml, I think. - Masaori On Fri, Mar 15, 2019 at 3: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 > >
