Re: Adding records consistency check for default values on startup - feedback wanted.

Here is an example of this problem. This could have been caught early: https://github.com/apache/trafficserver/blob/master/src/records/RecordsConfig.cc#L1337 thanks. On Thu, Aug 8, 2024 at 3:20 PM Damian Meden wrote: > Hi guys, wanted to get some feedback from you, so: > > &g

Adding records consistency check for default values on startup - feedback wanted.

Hi guys, wanted to get some feedback from you, so: *The goal:* Add records consistency check for default values on startup(core records and plugin records(TSMgmt*Create) Details: Working around some record consistency check issues this w

ATS 10 Metrics clear|reset at runtime.

Hello. With the latest inclusion of the new Metric machinery in ATS 10 you are no longer able to reset|zero a counter at runtime, this used to make sense as the old metrics were persistent, this is no longer the case for ATS 10. All counters are reset on every restart, so this would be the way to

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

I like the idea. +1 On Wed, Apr 10, 2024 at 10:49 PM Walt Karas wrote: > Yes, it's wrapper, that utilizes C++ features. It's easier to use (Imore > concise). Easy to understand. Can be intermixed with the base API. > > On Wed, Apr 10, 2024 at 12:49 PM Leif Hedstrom wrote: > > > Any specific

Re: [E] [PROPOSAL] Remove "proxy.process" prefix from all core metrics

sed to scope what's on the right side of the prefix. Damian. On Mon, Dec 18, 2023 at 6:17 PM Leif Hedstrom wrote: > > > > On Dec 18, 2023, at 3:40 AM, Damian Meden > > > wrote: > > > > +1 to remove the `proxy.process` > > > > I don't like e

Re: [E] Re: [PROPOSAL] Remove "proxy.process" prefix from all core metrics

> I did indeed try this route first, but it was difficult to find a solution that works with our tools. traffic_top (etc.) doesn’t read records.yaml, so it won’t know a change to the prefix. I think it will be doable to have a record_alias.json or something like that that traffic_ctl/top/etc maps

Re: [E] [PROPOSAL] Remove "proxy.process" prefix from all core metrics

+1 to remove the `proxy.process` I don't like either #1 or #2 although I agree to have a single prefix. I think eventually we will have this same conversation about `proxy.config` so to me a name that means the scope of the record should be used, `ats` seems too generic as can also be used by a co

Proposed new TS API function: TSRecYAMLConfigParse()

typedef TSReturnCode (*TSYAMLRecNodeHandler)(const TSYAMLRecCfgFieldData *cfg, void *data); tsapi TSReturnCode TSRecYAMLConfigParse(TSYaml node, TSYAMLRecNodeHandler handler, void *data); conf_remap currently has a copy of the records.config parsing logic inside the plugin's code. The idea with

Proposed new TS API function: TSYAMLCompatibilityCheck()

const char* TS_YAML_CPP_CORE_VERSION; int TS_YAML_CPP_CORE_VERSION_LEN; TSReturnCode TSYAMLCompatibilityCheck(const char *yamlcpp_lib_version, int yamlcpp_lib_len); This will be handy for several reasons: 1 - Avoid binary compatibility issues: Make sure that any plugin using a TS API with a TS

TSRecordModeType removal

Hello guys, this is part of some clean up I am doing related to the removal of Traffic Manager, so I am removing RecModeT from our source code as this is no longer needed, now it seems that we have a shared api TSRecordModeType so my question is, is anyone using this? I have a PR with this cleanu

Derivative Metrics removal.

Hello guys. In case you haven't noticed, our master branch no longer has the `traffic_manager` binary. There are still some references(docs, etc) and some other stuff that will be erased as well, but one of the things that seems to have been used by TM are the Derivative Metrics, *so with TM gone

Re: [E] Re: records.config to records.yaml

he same YAML format. Maybe we need to expose this as an > API to the plugin to avoid massive code duplications? > > — Leif > > > On Thursday, September 22, 2022 at 08:42:35 AM PDT, Damian Meden < > dme...@apache.org> wrote: > > > Hello guys, as a part of the movin

records.config to records.yaml

Hello guys, as a part of the moving to yaml, I plan to work on converting our records.config to records.yaml, this has been going on for a while now so hopefully I can get some traction now. As a *phase 1* of this task and aiming for 10 release, the plan is just to keep the original librecord inte

[API] - JSONRPC Plugin API proposal

Hello guys, As you all know there is a new JSONRPC implementation that is up for review which is intended to land in the 10-Dev branch. As a part of this effort and to use all the benefits of having such protocol in our ATS, I am proposing to add

Re: [E] Re: [DISCUSS] ATS code study groups

I'm on board! totally interested. Count me in. I also think, as was already said, having a video + tutorial would be ideal! Regards. Damian On Wed, Feb 3, 2021 at 8:16 AM Nick Kew wrote: > > > On 2 Feb 2021, at 23:20, Leif Hedstrom wrote: > > > >> On Feb 2, 2021, at 4:09 PM, Juncheng Yang

Re: [E] Re: [API] for accessing server session transaction count

Hello guys, this new API is now implemented -> https://github.com/apache/trafficserver/pull/7387 . Any feedback will be appreciated. The PR also includes a new header rewrite condition( SSN-TXN-COUNT) that consumes this new API. Regards, Damian. On Wed, Nov 18, 2020 at 10:59 PM Sudheer Vinukonda

Re: [E] [API] - TSMgmtDataTypeGet - Proposal

was just wondering if Dr. Zret > had > > other uses in mind. > > > > On Mon, Sep 28, 2020 at 5:07 PM Damian Meden < > > damian.me...@verizonmedia.com> > > wrote: > > > > > > for example, the name is passed as a plugin parameter or in a > &g

Re: [E] [API] - TSMgmtDataTypeGet - Proposal

or *TSMgmtFloatGet*. There is currently no way > to > > > know > > > > programmatically. The code has to "just know" which it is. > > > > > > > > On Mon, Sep 28, 2020 at 2:10 PM Walt Karas > > > .invalid> > > > > wrote

[API] - TSMgmtDataTypeGet - Proposal

Hi Guys. I would like to propose adding a new API function to bring the record data type from a particular record. A brief description of this new proposed API: *TSReturnCode TSMgmtDataTypeGet(const char * var_name, TSRecordDataType * result)* Get the type of a value for a configuration variab

Re: [PROPOSAL] GitHub change to Squash and Merge

+1 On Mon, Jun 15, 2020 at 3:49 PM Walt Karas wrote: > +1 as long as it doesn't cause uncommented commits. > > On Mon, Jun 15, 2020 at 9:43 AM Steven R. Feltner > wrote: > > > +1 > > > > On 6/14/20, 11:32 AM, "Bryan Call" wrote: > > > > Notice: This email is from an external sender. > > >

Proposal: Add configuration support & retry variance for existing exponential backoff on traffic manager

Context If there is any problem with traffic server which causes the server not to start, traffic manager will retry using an exponential sleep time till it hits the max sleep time which is currently hardcoded at 60 seconds, once this is reached, traffic manager this retry indefinitely. Problem