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
