trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Rushford <>
Subject Re: [PROPOSAL] YAML migration for 9.0.0
Date Mon, 18 Mar 2019 22:45:53 GMT
I'm +1 but with that said, there are 3 configs that use the
proxy/ControlMatcher, hosting.config, parent.config, and splitdns.config.
I worked on a PR for parent.config,,
and made changes to the ControlMatcher to parse YAML for the
parent.config.  The change looks at the filename and only uses the YAML
parser if the filename ends in .yaml otherwise it parses using the current
This change let me add support for parsing the parent.config without having
to convert hosting.config and splitdns.config at the same time.  I went
this way thinking that once all the users of the ControlMatcher had been
the old format could then be removed and a single massive PR would not be
needed for converting all 3 config files.

On Mon, Mar 18, 2019 at 2:39 PM Randall Meyer <>

> +1
> On Monday, March 18, 2019, 11:14:20 AM PDT, Bryan Call <>
> wrote:
> + 1
> -Bryan
> 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

John Rushford

View raw message