> On Sep 5, 2023, at 8:49 PM, Sudheer Vinukonda
> wrote:
>
> That said, seems like a similar use case could be, if we ever wanted to
> persist an origin server error rate or down status etc or anything that’s
> dynamic similar to the administratively disabling h2 support status.
Right, fo
That said, seems like a similar use case could be, if we ever wanted to persist
an origin server error rate or down status etc or anything that’s dynamic
similar to the administratively disabling h2 support status.
> On Sep 5, 2023, at 7:45 PM, Sudheer Vinukonda
> wrote:
>
> Ugh sorry, shou
Ugh sorry, should’ve read carefully - the use case seems more related to
turning on/off h2 at a individual server level (and not at an origin level) and
not a origin configuration which is unrelated.
Sorry for the confusion!
> On Sep 5, 2023, at 7:33 PM, Sudheer Vinukonda
> wrote:
>
> Yea
Yeah, I meant the origin server session sharing configuration is a similar
example to that of configuring an origin’s H2 support that was brought up, not
that it’s related to HostDB.
> On Sep 5, 2023, at 7:12 PM, SUSAN HINRICHS wrote:
>
> I am also ok with removing the hostdb persistence.
>
I am also ok with removing the hostdb persistence.
I am confused about how this is similar to origin server session sharing.
On Tue, Sep 5, 2023, 6:12 PM Sudheer Vinukonda
wrote:
> >> I think this is similar to the the current and existing ugliness we
> have around marking parents down as well
See https://github.com/apache/trafficserver/pull/10375 .
>> I think this is similar to the the current and existing ugliness we have
>>around marking parents down as well (which uses librecords and persistent
>>metrics to store string values). That’s not great either, so a general
>>concept of a persistent key-value store is needed already! I thin
> On Sep 5, 2023, at 3:59 PM, Masakazu Kitajo wrote:
>
> Sounds reasonable.
>
> Just one question. What would be the best places to store information like
> "This origin server supports / prefers / breaks H2" ? We might want to
> administratively disable H2-to-Origin for a particular origin s
Sounds reasonable.
Just one question. What would be the best places to store information like
"This origin server supports / prefers / breaks H2" ? We might want to
administratively disable H2-to-Origin for a particular origin server. We
currently don't use HostDB for it but I'm not sure where we
Where would we put it? Just copy it into each plugin where it's used?
Have each plugin rewrite code to support RAII?
On Tue, Sep 5, 2023 at 1:01 PM Chris McFarlen wrote:
> I would advocate for a much higher level plugin API in the direction of
> Cripts that encapsulates much of the minutia of h
> On Sep 5, 2023, at 9:44 AM, David Carlin wrote:
>
> These settings are for /etc/hosts - are their removal required to get rid
> of persistent storage?
>
>proxy.config.hostdb.host_file.path
>proxy.config.hostdb.host_file.interval
Ok, I’ve updated the PR, which retains the /etc/host
I would advocate for a much higher level plugin API in the direction of Cripts
that encapsulates much of the minutia of hooking into the transaction lifecycle
and reduces the rote boilerplate that exists in current plugins. Hopefully
something that will cover the vast majority of use cases with
Would it be possible to propose concrete alternatives? We can't just
simply delete Cleanup.h, the xdebug plugin won't compile.
On Tue, Sep 5, 2023 at 12:27 PM Chris McFarlen wrote:
> I have read through Cleanup.h and its uses and I agree this is not a style
> we should promote. This code alrea
Ah, makes sense - Apologies, I misunderstood/misread the original email as we
are removing HostDB altogether. Looks like the proposal is to only remove the
persistence of HostDB. Agree that there is very little value with HostDB
persistence today and you are correct that we are not leveraging t
I have read through Cleanup.h and its uses and I agree this is not a style we
should promote. This code already feels like tech debt in that its bridging C
and C++ APIs in a bolt-on fashion that I think we will want to deprecate
shortly.
While certainly RAII and "smart" pointers are important
> On Sep 5, 2023, at 9:53 AM, Sudheer Vinukonda
> wrote:
>
> To minimize the impact on the existing users, should we keep the feature (in
> the same disabled state) until an alternative is added/supported?
No :). There won’t be an alternative added, either we keep what we have, or we
remo
> On Sep 5, 2023, at 9:44 AM, David Carlin wrote:
>
> These settings are for /etc/hosts - are their removal required to get rid
> of persistent storage?
>
>proxy.config.hostdb.host_file.path
>proxy.config.hostdb.host_file.interval
Hmmm, that was not the intent, let me look at the co
I was not talking about the need to use RAII. I just don't think we should
promote Cleanup.h.
On Tue, Sep 5, 2023 at 7:28 AM Walt Karas
wrote:
> It seems that some are not convinced of the need to use RAII. I won' t get
> into that, it's easy to find writeups advocating for it, which are better
To minimize the impact on the existing users, should we keep the feature (in
the same disabled state) until an alternative is added/supported?
On Tuesday, September 5, 2023 at 08:38:03 AM PDT, Leif Hedstrom
wrote:
I’d like to remove the feature for persistent HostDB storage for ATS v10
These settings are for /etc/hosts - are their removal required to get rid
of persistent storage?
proxy.config.hostdb.host_file.path
proxy.config.hostdb.host_file.interval
Using /etc/hosts is very useful for troubleshooting, so I can point to a
specific origin server temporarily and still
I’d like to remove the feature for persistent HostDB storage for ATS v10.0. In
ATS v9 we made this disabled by default, and removing this feature completely
would make it easier in the future to improve and replace HostDB itself with
better containers. And, persistent DNS caching is better done
It seems that some are not convinced of the need to use RAII. I won' t get
into that, it's easy to find writeups advocating for it, which are better
than anything I could write.
I have no strong feelings about how things are spelled or abbreviated.
On Sat, Sep 2, 2023 at 11:22 PM James Peach wr
22 matches
Mail list logo
