> On Mar 14, 2019, at 1:29 PM, John Rushford <jrushf...@apache.org> wrote:
>
> Leif,
>
> Your proposal seems fine to me. I have a PR on github that converts the
> existing parent.config to YAML,
> https://github.com/apache/trafficserver/pull/4857
> 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.
Yes, this is fine, as a transitional step. What the proposal does is that we
all agree that before we release v9.0.0, we kill old configurations that now
have YAML.
Having these transitional steps is definitely a good idea, and lets us test
master with less pain. I’d say keep #4857 as is.
Cheers,
— Leif
>
> 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?
>
> thanks
> John Rushford
> jrushf...@apache.org
>
> On Thu, Mar 14, 2019 at 12:26 PM 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
>>
>>
