trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Call <>
Subject Re: [PROPOSAL] YAML migration for 9.0.0
Date Mon, 18 Mar 2019 18:14:16 GMT
+ 1


> On Mar 14, 2019, at 11:26 AM, Leif Hedstrom <> 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

View raw message