trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Masaori Koshiba <masa...@apache.org>
Subject Re: [PROPOSAL] YAML migration for 9.0.0
Date Thu, 14 Mar 2019 23:07:02 GMT
>
> 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


Is "proxy.config.ssl.server.multicert.filename" also included? It will be
ssl_multicert.yaml, I think.

- Masaori

On Fri, Mar 15, 2019 at 3:26 AM Leif Hedstrom <zwoop@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
>
>

Mime
View raw message