You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2019/03/14 18:26:55 UTC
[PROPOSAL] YAML migration for 9.0.0
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
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by Leif Hedstrom <zw...@apache.org>.
> On Mar 14, 2019, at 5:07 PM, Masaori Koshiba <ma...@apache.org> wrote:
>
> proxy.config.ssl.server.multicert.filename
Yes, it should also be removed.
— leif
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by Leif Hedstrom <zw...@apache.org>.
> On Mar 14, 2019, at 5:07 PM, Masaori Koshiba <ma...@apache.org> wrote:
>
> proxy.config.ssl.server.multicert.filename
Yes, it should also be removed.
— leif
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by Masaori Koshiba <ma...@apache.org>.
>
> 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 <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
>
>
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by John Rushford <jj...@gmail.com>.
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,
https://github.com/apache/trafficserver/pull/4857,
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
format.
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
converted,
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 <ra...@yahoo.com>
wrote:
> +1
>
> On Monday, March 18, 2019, 11:14:20 AM PDT, Bryan Call <bc...@apache.org>
> wrote:
>
>
> + 1
>
> -Bryan
>
>
>
> On Mar 14, 2019, at 11:26 AM, 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
>
>
>
--
John Rushford
jjrushford@gmail.com
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by Randall Meyer <ra...@yahoo.com>.
+1
On Monday, March 18, 2019, 11:14:20 AM PDT, Bryan Call <bc...@apache.org> wrote:
+ 1
-Bryan
On Mar 14, 2019, at 11:26 AM, 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
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by Bryan Call <bc...@apache.org>.
+ 1
-Bryan
> On Mar 14, 2019, at 11:26 AM, 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
>
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by Bryan Call <bc...@apache.org>.
+ 1
-Bryan
> On Mar 14, 2019, at 11:26 AM, 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
>
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by Leif Hedstrom <zw...@apache.org>.
> On Mar 14, 2019, at 1:29 PM, John Rushford <jr...@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
> jrushford@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
>>
>>
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by John Rushford <jr...@apache.org>.
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
jrushford@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
>
>
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by Masaori Koshiba <ma...@apache.org>.
>
> 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 <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
>
>
Re: [PROPOSAL] YAML migration for 9.0.0
Posted by John Rushford <jr...@apache.org>.
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
jrushford@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
>
>