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 Thu, 14 Mar 2019 19:29:22 GMT

Your proposal seems fine to me.  I have a PR on github that converts the
existing parent.config to YAML,
In this PR, I had made it backwards compatible with the existing format.
The change involves a lot of changes to the ControlMatcher which is also
used by other configs.

Based upon your proposal, I can go back and remove the backwards
compatibility and just support YAML.  But, I would only use the existing
parent.config variables perhaps renaming
those to the nexthop naming we discussed last summer.  This would be the
initial PR just to convert to YAML.  As the conversion to the next hop
stuff would involve a lot more work, I
think that would come in later PR's.  How does that sound?

John Rushford

On Thu, Mar 14, 2019 at 12:26 PM 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