trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert O Butts <...@apache.org>
Subject Re: Converting "records.config" to YAML
Date Wed, 20 May 2020 22:07:46 GMT
While we're changing it, thoughts on descriptive text instead of numbers
for enums? `insert_request_via: basic_transaction_codes` instead of
`insert_request_via: 2` ?


On Wed, May 20, 2020 at 3:52 PM Leif Hedstrom <zwoop@apache.org> wrote:

>
>
> On May 20, 2020, at 3:35 PM, Alan Carroll <
> solidwallofcode@verizonmedia.com> wrote:
>
> Dang, you guys were all "flat name space!" at the hackathon.
>
> As you can see from my example, I did clean up the name space a bit and
> removed a "config" from those (e.g. "proxy.config.http.cache" is the
> current name). We could remove "proxy" as well.
>
>
>
> Pretty sure I would not have agreed to keep the existing name space. I
> don’t consider the one we have “flat” though, it’s definitely a hierarchy.
> However, that hierarchy is not well designed, definitely not well
> maintained and absolutely not consistent.
>
> My suggestion is, when we do this, lets also clean this up. As a bonus,
> it’s likely that the same hierarchy could be incorporated into how we use
> Debug(), to make it a lot more easy to trace on some particular portion of
> the feature/configuration hierarchy, and have it do so reliably. The bonus
> here then is that we have one name space to maintain, and document.
>
> — Leif
>
>
> Sudheer's question is a good one that I"ve been pondering.
>
> 1) This would only be "records.config". It's too much to convert
> everything to YAML, but every file we change is one step closer to full
> YAML. ("Never go full YAML" - Leif)
>
> 2) Overrides would need to use the full name. For the flat style this is
> trivial because that's the same as the key name. For the tree, we'd need a
> notation to indicate descent along the objects. A simple rule would be to
> forbid a name to contain "." and then use "." as a separator that indicates
> to descend. Then the names would again be exactly as they are now and no
> changes would be needed. This isn't really any different from file system
> paths or FQDNs, so I don't think it will be a large hurdle for ATS ops
> people.
>
> On Wed, May 20, 2020 at 3:22 PM Leif Hedstrom <zwoop@apache.org> wrote:
>
>> IF we are going down this path, we should restructure the configuration
>> name space now too. A lot of things makes no sense any more, including the
>> proxy. prefix.
>>
>> I do agree with Randal though, we should use proper YAML structure for
>> the name spaces, for both configurations and metrics.
>>
>> — leif
>>
>>
>> On May 20, 2020, at 1:18 PM, Randall Meyer <randallmeyer@yahoo.com>
>> wrote:
>>
>> I vote for #2, though I could live with either.
>>
>> -r
>>
>> On Wednesday, May 20, 2020, 11:09:25 AM PDT, Alan Carroll <
>> solidwallofcode@verizonmedia.com> wrote:
>>
>>
>> If "records.config" is changed to be YAML for ATS 10, there are two
>> reasonable approaches to changing it.
>>
>> Option 1) Use a flat namespace. The file would look something like
>>
>> config:
>>    proxy.http.cache: true
>>    proxy.http.insert_request_via_str: 2
>>    proxy.http.chunking_enabled: true
>>    proxy.dns.resolv_conf: "/etc/resolv.conf"
>>    # .... etc.
>>
>> Option 2) Use a tree. The file would look something like
>>
>> config:
>>    proxy:
>>       http:
>>          cache: true
>>          insert_request_via: 2
>>          chunking_enabled: true
>>       dns:
>>          resolv_conf: "/etc/resolv.conf"
>>
>> From an automation point of view these are not really different - there
>> is an obvious isomorphism between them such that converting between them is
>> trivial.
>>
>> Any comments?
>>
>>
>>
>

Mime
View raw message