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.
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 > >
