Re: [Deprecation Proposal]

+1 — leif > On Feb 25, 2025, at 10:22 AM, Evan Zelkowitz wrote: > > I'd like to propose deprecating parent.config with ATS 10.1. Allow this to > continue through the 10x series and then remove it with ATS 11.x in favor of > strategies > > Strategies has been considered production ready for

Re: Upgrade to CMake 3.24

I’m fine with that but probably should be done for v11 release. Another incentive to move forward :). — Leif On Thu, Feb 13, 2025 at 16:58 Mo Chen wrote: > Context: https://github.com/apache/trafficserver/pull/12035 > > I'd like for us to upgrade to CMake 3.24 so that support for link groups is

Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol

I’m +1 too. Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper case) instead of PP, which is how it’s spelled. — Leif On Sat, Feb 8, 2025 at 20:03 Brian Neradt wrote: > +1 > > My preference would be to spell out ProxyProtocol in the API instead of > PP. But I don't feel

Re: Is anyone using the internal header @WWW-Auth ?

Forgot about this, and there was no replies, so I’d like to remove this @WWW-auth (internal only) header from ATS v11.0. — Leif > On Sep 19, 2024, at 2:32 PM, Leif Hedstrom wrote: > > While poking around mime headers, I noticed we have a special case around > this internal heade

Re: [VOTE] Release Apache Traffic Server 9.2.8 (RC0)

+1 — Leif On Wed, Jan 29, 2025 at 14:39 Evan Zelkowitz wrote: > I've prepared a release for 9.2.8. The release notes are available at: > > https://github.com/apache/trafficserver/milestone/80?closed=1 > > > https://docs.trafficserver.apache.org/en/latest/release-notes/upgrading.en.html > >

Re: [VOTE] Release Apache Traffic Server 9.2.6 (RC0)

+1. — Leif > On Nov 12, 2024, at 1:31 PM, Evan Zelkowitz wrote: > > I've prepared a release for 9.2.6. The release notes are available at: > > https://github.com/apache/trafficserver/milestone/77 > https://docs.trafficserver.apache.org/en/latest/release-notes/upgrading.en.html > > or for a

Is anyone using the internal header @WWW-Auth ?

While poking around mime headers, I noticed we have a special case around this internal header, @WWW-Auth. If set, it seems it can force cached content to be reauthenticated on every request. This is handled by setting the t_state.www_auth_content when this header is there. Now, there’s nothing

[Proposal] New plugin API TSMBufferIsValid

I’d like to add this new TS API: /** Check to see if an MBuffer is still valid, from since the time it was acquired. */ bool TSMBufferIsValid(TSMBuffer bufp); The intent of this API is to check if a TSMbuffer, and any pointers related to this buffer, are still valid. Why would they not b

Re: [VOTE] ACL filter action names for 10.x

I’ll vote for 2 but I’ll survive with 1 as well. 2 has the benefit of allowing us to make the old verbs a syntax error in v11 rather than semantically change their behavior causing unexpected problems. — Leif On Mon, Jul 29, 2024 at 11:42 Bryan Call wrote: > +1 for 1. Keep the allow/deny actio

Re: [VOTE] Release Apache Traffic Server 8.1.11 (RC0)

+1 — Leif

Re: [VOTE] Release Apache Traffic Server 9.2.5 (RC0)

+1. — Leif

Re: ATS 10 Metrics clear|reset at runtime.

I’m +1 on removing the “clear|zero” operations from traffic_ctl in 10.0.0. — Leif > On Jul 16, 2024, at 4:12 AM, Damian Meden wrote: > > 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 se

Re: API Change for TSMimeHdrPrint

On Mon, Jun 10, 2024 at 13:59 wrote: > Hello, > > After a refactor, the first parameter to TSMimeHdrPrint is unused, and we > are planning on removing it for ATS 10. The API will be changed as in the > following diff: > > -void TSMimeHdrPrint(TSMBuffer bufp, TSMLoc offset, TSIOBuffer iobufp); > +

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

> On Apr 18, 2024, at 11:20 AM, Masakazu Kitajo wrote: > > Like I said above, I think we should keep TS API minimal, because we cannot > change TS API casually. Once we add something, it's difficult to change or > remove it. I don't want to have much code with such constraints just for > conve

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

Any specific justifications for this? This is another abstraction of the C APIs in C++? — Leif On Mon, Apr 8, 2024 at 13:28 Walt Karas wrote: > That is move plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h > to include/ts, and plugins/experimental/txn_box/plugin/src/ts_util.cc to >

Re: [VOTE] Release Apache Traffic Server 8.1.10 (RC0)

+1 > On Apr 3, 2024, at 10:03 AM, Evan Zelkowitz wrote: > > I've prepared a release for 8.1.10. The release notes are available at: > >https://github.com/apache/trafficserver/milestone/71?closed=1 > > or for a brief ChangeLog: > >https://github.com/apache/trafficserver/blob/8

[PROPOSAL] New Get() API for the Txn error body

We have an existing API to set the error body (TSHttpTxnErrorBodyGet() ), and I’d like to add the corresponding Get’er for this. I’m proposing the following: /** Retrives the error body, if any, from a transaction. This would be a body as set via the API body. @param txnp

10.0.x branched

Hi all, Sorry for the delays, but we’re finally ready to begin the 10.0.x release cycle. I’ve branched current master today, which is named 10.0.x. There are a few implications with this branch, as per the new release process that was agreed upon quite a while ago. The three laws of master bran

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

at the time. :). I can look again. — Leif > > On Mon, Dec 18, 2023 at 9:03 PM Leif Hedstrom wrote: > >> >> >>> On Dec 18, 2023, at 21:20, Walt Karas >> wrote: >>> >>> Is the current naming based on some SNMP MIB spec? >> >>

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

ut 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. — Leif > >> On Mon, Dec 18, 2023 at 9:41 PM James Peach wrote: >> >> >> >>>> On 18 Dec 2023, at

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

ready :). — Leif > > Thanks. > Damian. > > On Mon, Dec 18, 2023 at 3:29 AM Leif Hedstrom wrote: > >> Through all our cleanup and refactoring in the past, as far as I can tell, >> all metrics are now prefixed with proxy.process. >> >> This seems a l

Re: New feature suggestion: ip_category for ip_allow.yaml

How is this going to deal with changes to the data source? The plugin has to reload the e tire data set, and we do an atomic swap or something? This seems particularly unmanageable when the data source is large, and/or it changes frequently. This also implies that one IP range can have just one

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

Through all our cleanup and refactoring in the past, as far as I can tell, all metrics are now prefixed with proxy.process. This seems a little superfluous. I’d like to suggests one of two options: 1. Just drop the prefix entirely. 2. Replace the prefix with “ats”. Thoughts? — Leif

[Proposal] Remove tsxs from ATS v10.0.0

We’ve discussed of this tool in slack and meetup, and the consensus is that with the migration to CMake, using the cmake or package config tools eliminates the need for this old tool. So the suggestion is that we’ll remove it from ATS v10. Let us know if you have a problem with this by replyi

[Proposal] Remove WCCP from ATS v10.0.0

Hi y’all, I’d like to propose that we remove all WCCP support and code from ATS v10.0.0. WCCP is a protocol that isn’t maintained and supported by Cisco, and hasn’t been for a long time. It’s lacking in important “modern” features such as IPv6. If anyone still has a use or need of WCCP, please

[PROPOSAL] Remove the old HTTP stats and cache inspection pages

I’d like to propose that we remove these pages from the ATS v10 release. Not only are they not maintained (and haven’t been for a long time, so some of it doesn’t work), they generally don’t have a whole lot of useful information. The notion of running this (sort of ) minimal HTTP server inside

[PROPOSAL] Remove the experimental/cache_key_genid plugin for v10.0.0

This plugin is experimental, not maintained, and I think not used (there are better ways to manage genIDs now). Removing it simplifies our build system, and maintenance of plugins. Let us know if you have a problem wit this — Leif

Re: [API proposal] TSHttpSsnInfoIntGet

+1 As for experimental, I think we mostly decided to stop using this. In fact we should remove / move what’s left there IMO. — Leif > On Oct 25, 2023, at 14:10, Masakazu Kitajo wrote: > > Hi, > > I'd like to add TSHttpSsnInfoIntGet to TS API. The API documentation is on > the PR below: > h

[API proposal] Adding a third optional argument to TSMgmtUpdateRegister

I’d like to update the existing API for TSMgmtUpdateRegister(), to add a third, optional argument: void TSMgmtUpdateRegister(TSCont contp, const char *plugin_name, const char *plugin_file_name = nullptr); The old behavior (without providing this plugin_file_name) remains the same. However, w

Re: Proposed new TS API function: TSContScheduleOnEntirePool

e, Oct 17, 2023 at 10:09 AM Leif Hedstrom wrote: >> >> I assume “every” can be zero for a one time shot on every thread of the >> specified type? >> >> — Leif >> >>>> On Oct 17, 2023, at 07:26, Fei Deng wrote: >>> >>> tsapi:

Re: Proposed new TS API function: TSContScheduleOnEntirePool

I assume “every” can be zero for a one time shot on every thread of the specified type? — Leif > On Oct 17, 2023, at 07:26, Fei Deng wrote: > > tsapi::c::TSAction > tsapi::c::TSContScheduleEveryOnEntirePool(TSCont contp, TSHRTime every, > TSThreadPool tp); > > With this we can schedule a co

Re: Proposed new API: TSVConnFdGet

> On Sep 6, 2023, at 4:26 PM, SUSAN HINRICHS wrote: > > I would like to add a convenience API to fetch the file descriptor from a > VConn object. I came across the need for this when writing a plugin > working with a SSL VConn. For a variety of reasons, I didn't want the > plugin to link wit

Re: Proposal: TS API: Don' t require a DbgCtl instance of have a tag when constructed.

> On Sep 5, 2023, at 6:30 PM, Walt Karas wrote: > > See https://github.com/apache/trafficserver/pull/10375 . Love it. — Leif

Re: [PROPOSAL] Remove persistent storage for HostDB

hink >>>>> your use case falls inline with what we need to do for the parent host >>>>> up/down state as well, so even more reasons why we need that :). >>>>> +1 >>>>> Another similar example that comes to mind is the Origin Server Sessi

Re: [PROPOSAL] Remove persistent storage for HostDB

> 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

Re: [PROPOSAL] Remove persistent storage for HostDB

nce. Thanks! — Leif > > Using /etc/hosts is very useful for troubleshooting, so I can point to a > specific origin server temporarily and still have the proper SNI and host > header. > > On Tue, Sep 5, 2023 at 11:38 AM Leif Hedstrom wrote: > >> I’d like to remove the featur

Re: [PROPOSAL] Remove persistent storage for HostDB

ries are likely already expired anyways. The whole point of removing this in v10.0 is that it would allow us (with less effort) to replace HostDB with something better, without having to wait until v11.0. Cheers, — Leif >On Tuesday, September 5, 2023 at 08:38:03 AM PDT, Leif Hedstrom &g

Re: [PROPOSAL] Remove persistent storage for HostDB

> 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

[PROPOSAL] Remove persistent storage for HostDB

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

[DISCUSS] Can we replace / eliminate some "avg" and "per_sec" metrics?

While going through ATS to rewrite the metrics (still being evaluated if viable), I’ve come to realize that we have a number of metrics that are not particularly useful. What’s worse, there’s some serious implications for these particular metrics making the calculation of them expensive and comp

Re: [E] [VOTE] Removing example/plugins/cpp-api

> On Aug 17, 2023, at 07:11, Walt Karas wrote: > > Does anyone have objections to the general plan to deprecate the C++ API? I’m ok deprecating it :). > > Since include/tscpp/api/Cleanup.h is distinct from the rest to the C++ API > (designed to support the C-style API rather than enacapsula

Re: [VOTE] Release Apache Traffic Server 9.2.2 (RC0)

+1 — Leif > On Aug 2, 2023, at 11:09 AM, Bryan Call wrote: > > I've prepared a release for 9.2.2. The release notes are available at: > > > https://github.com/apache/trafficserver/pulls?q=is:closed+is:pr+milestone:9.2.2 > > or for a brief ChangeLog: > > https://github.com/apac

Re: [proposal] Minimum supported version for openssl is 1.1.1 for ATS 10.

tion. Perhaps in a year, we should re-evaluate 1.1.1 support. +1 — Leif > >> On Sun, Jun 25, 2023 at 12:45 AM James Peach wrote: >> >> >> >>>> On 25 Jun 2023, at 1:13 pm, Leif Hedstrom wrote: >>> >>> We don’t really support OS v

Re: [proposal] Minimum supported version for openssl is 1.1.1 for ATS 10.

We don’t really support OS versions per se anymore. The one most people used to use, CentOS 7, is so outdated that its toolsets and libraries are not usable. Rather, we set version requirements on all the dependencies. This was done a few years ago, and that’s what Chris is suggesting we update

Re: [VOTE] Release Apache Traffic Server 8.1.7 (RC0)

+1 — leif > On Jun 7, 2023, at 6:12 PM, Evan Zelkowitz wrote: > > I've prepared a release for 8.1.7. The release notes are available at: > > > https://github.com/apache/trafficserver/pulls?q=is:closed+is:pr+milestone:8.1.7 > > or for a brief ChangeLog: > >https://github.com/apache

Re: [VOTE] Release Apache Traffic Server 9.2.1 (RC0)

+1 — Leif > On Jun 7, 2023, at 5:59 PM, Bryan Call wrote: > > I've prepared a release for 9.2.1. The release notes are available at: > > > https://github.com/apache/trafficserver/pulls?q=is:closed+is:pr+milestone:9.2.1 > > or for a brief ChangeLog: > > https://github.com/apach

[Discuss, Proposal] Plugins promotions, deprecations and removals for ATS v10.0.0

Hi all, as part of our major release cleanup, I’d like to make the following proposals to the current set of plugins. Please let us know if you have problems with any of these changes, if not, lazy consensus applies. Remove these plugins: - * parent_select - This is mo

[PROPOSAL] New API to look up strings against our set of WKS constants

Hi, In our code, we have a concept of well-known-strings (WKSs). These are used to sort of normalize common header and URL strings, and can be used in some cases for optimizing lookups in request header heaps etc. When a plugin uses a WKS directly, such as TS_MIME_FIELD_CACHE_CONTROL to look fo

Re: Feedback on removing AIO_MODE_NATIVE from iocore/aio

> On May 4, 2023, at 2:50 PM, Bryan Call wrote: > > It is an experimental feature that isn’t used to my knowledge. I am ok with > removing it for 10.x. > > If it was a supported feature then we should do the deprecation in one major > version and then remove it in the next major version pr

Re: Proposed new TS API function: TSYAMLCompatibilityCheck()

Hmmm, I’m not sure about this. Two reasons 1. We have compatibility checks already for plugins, and whatever yaml versions we have wi5 in a major version ought to always be compatible. If a plug-in uses TSYAML APIs, its compatibility ought to be guaranteed with the major version of ATS. This wo

Re: Feedback on removing AIO_MODE_NATIVE from iocore/aio

> On Apr 3, 2023, at 11:38, Chris McFarlen wrote: > > I would like to remove this disk IO mode from ATS. If nobody is using it, > then I'd like to delete it for the 10.x release. If that isn't possible, I > think it should be deprecated in favor of io_uring and removed in a future > versio

Re: Derivative Metrics removal.

> On Feb 14, 2023, at 9:47 AM, Damian Meden wrote: > > 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 t

[proposal] Labels for plugins in Github

Hi y’all, we’re busy working on all the new stuff in prep for 10.0.0 and new release systems and branch management. I’d like to propose one more thing: Today, we use the Label “Plugins” as a catch all for plugins. This is good (and we should continue to use that). I’d like to propose that we al

Github Projects

Going forward, we’ll use the new Project system on Github. I’ve moved the old 10.x project to this system: https://github.com/orgs/apache/projects/204/views/1 There’s still more work to be done here. The old 9.x and 8.x Projects will not be migrated to the new system. — leif

Re: New branch management process (starting with 10.0.0)

Here that should beATS Release Roadmap — Apache Traffic Server 10.0.0 documentationtrafficserver.apache.orgOn Jan 31, 2023, at 16:52, Leif Hedstrom wrote:Hi all,as discussed at the last summit, we’re proposing a change to branch management, to hopefully improve on both quality/stability as well

New branch management process (starting with 10.0.0)

Hi all, as discussed at the last summit, we’re proposing a change to branch management, to hopefully improve on both quality/stability as well as better release management. The big change is that we will no longer propose and cherry-pick PRs from master branch to the release branch. Rather, we

[ANNOUNCE] Apache Traffic Server v9.2.0 is Released!

Apache Traffic Server v9.2.0 Released The Apache Software Foundation and the Apache Traffic Server (ATS) project are pleased to announce the release of Apache Traffic Server v9.2.0! ATS is a high performance, scalable HTTP Intermediary and proxy cache. It is used by several large internet servi

Re: [VOTE] Release Apache Traffic Server 9.2.0 (RC0)

ficserver > > Building on rawhide required a (very minor) patch to support glibc 2.37 > changes (PR#9325), as did re-enabling the ppc64le arch (#9326). Awesome, thank you. We will include this with v9.2.1. Cheers, — Leif > > --Jered > > - On Jan 19, 2023, at 9:25 PM, Le

Re: [VOTE] Release Apache Traffic Server 9.2.0 (RC0)

> On Jan 12, 2023, at 12:01 PM, Leif Hedstrom wrote: > > I've prepared a release for 9.2.0 (RC0), which is a minor release for 9.x, > and is still backwards compatible with all previous 9.x releases. This adds > quite a few new features, performance improvements and ma

Re: [VOTE] Release Apache Traffic Server 9.2.0 (RC0)

+1 from me as well, of course. — Leif > On Jan 12, 2023, at 12:01 PM, Leif Hedstrom wrote: > > I've prepared a release for 9.2.0 (RC0), which is a minor release for 9.x, > and is still backwards compatible with all previous 9.x releases. This adds > quite a few new f

[VOTE] Release Apache Traffic Server 9.2.0 (RC0)

I've prepared a release for 9.2.0 (RC0), which is a minor release for 9.x, and is still backwards compatible with all previous 9.x releases. This adds quite a few new features, performance improvements and many bug fixes. All in all, there are 588 PRs in this release, and is the result of well

Re: [E] Proposed change to TS API: TSHeapBuf

f any changes. Of course, they can’t use any new APIs, or new structures added that are C++. — leif > > On Wed, Jan 4, 2023 at 1:10 PM Leif Hedstrom wrote: > >> This looks like a string_view to me? >> >> Why don’t we do what we talked about for years now, and stop

Re: [E] Re: Proposed change to TS API: TSHeapBuf

This looks like a string_view to me? Why don’t we do what we talked about for years now, and stop supporting compiling plug-ins with C but require C++? Then we can introduce nice things in ts.h. The old C plugins just have to be changed to compile with C++, and ABI compatibility within major v

Re: [VOTE] Release Apache Traffic Server 9.1.4 (RC0)

+1 > On Dec 15, 2022, at 12:40, Bryan Call wrote: > > I am calling the vote with 4 +1 votes. We will publish the final release > today. > > -Bryan > >> On Dec 14, 2022, at 10:54 AM, Bryan Call wrote: >> >> I've prepared a release for 9.1.4. The release notes are available at: >> >>

Re: records.config to records.yaml

> On Sep 22, 2022, at 9:49 AM, Sudheer Vinukonda via users > wrote: > > My vote is for #2 (ie support a single format), but, if possible, it'd be > great if we can automatically convert the existing config files into YAML as > part of the upgrade. At the very least, we should provide a tool

9.2.0 release plans

Hi all, We would like to aim for a 9.2.0-RC0 candidate to be voted on, with the following dates: 10/17: RC0 candidate made available, and to be tested / voted upon 10/21: Release of 9.2.0 (assuming it passes) It’s important that testing starts as soon as possible, so that if ne

Re: [VOTE] Release Apache Traffic Server 8.1.4 (RC0)

+1, verified, built, tested on macOS. There are some compiler warnings that should be addressed for v8.1.5, but not critical for v8.1.4. — leif > On Mar 16, 2022, at 15:24, Evan Zelkowitz wrote: > > I've prepared a release for 8.1.4 (RC0), which is a bug fix release for 8.1.x > and is backw

[ANNOUNCE] Apache Traffic Server v9.1.2 is Released!

Apache Traffic Server v9.1.2 Released The Apache Software Foundation and the Apache Traffic Server (ATS) project are pleased to announce the release of Apache Traffic Server v9.1.2! ATS is a high performance, scalable HTTP Intermediary and proxy cache. It is used by several large internet servi

Re: [VOTE] Release Apache Traffic Server 9.1.2 (RC1)

Calling this vote, with 3 +1 votes(one from me as well obviously). Will upload the artifacts momentarily, and then send the announcement. — leif > On Feb 28, 2022, at 17:47, Leif Hedstrom wrote: > > I've prepared a release for 9.1.2 (RC1), which is a bug fix release for 9

[VOTE] Release Apache Traffic Server 9.1.2 (RC1)

I've prepared a release for 9.1.2 (RC1), which is a bug fix release for 9.1.x and is backwards compatible. This adds a few fixes that was proposed after the first RC0 candidate. For a list of all PRs in this release, see https://github.com/apache/trafficserver/milestone/55?closed=1 or

Managing PRs on Github

Hi all, So, this is a not so gentle reminder that you have to bloody manage the various Github fields for PRs. In particular: Milestone - Should always be 10.0.0 (for now), unless it’s a requested back port PR (because of merge conflicts) Projects - If needed, adding e.g. 9.2.x

Re: [EXTERNAL] [VOTE] Release Apache Traffic Server 9.1.2 (RC0)

7;s an experimental plugin, but it does involve hard casting an int* into a > size_t* before calling TSBase64Decode. > > On 2/15/22, 10:43 PM, "Leif Hedstrom" wrote: > >I've prepared a release for 9.1.2 (RC0), which is a bug fix release for > 9.1.x and

[VOTE] Release Apache Traffic Server 9.1.2 (RC0)

I've prepared a release for 9.1.2 (RC0), which is a bug fix release for 9.1.x and is backwards compatible. For a list of all PRs in this release, see https://github.com/apache/trafficserver/milestone/55?closed=1 or for a brief ChangeLog (also attached below): https://github.com

Re: Open an issue for --enable-debug binaries?

> On Jan 24, 2022, at 2:37 PM, CHOU, PETER wrote: > > Hi, > > Should I open an issue for a fault, such as an assertion failure, that only > happens with binaries compiled with the '-enable-debug' option? Right, most of our assertions are (and should be!) debug only assertions. This is as i

Re: "F2F" (well, online) working group for a release schedule proposal

Ping on this, there has to be more than three people who cares about the next ~year releases? — Leif > On Nov 17, 2021, at 1:11 PM, Leif Hedstrom wrote: > > Hi all, > > As discussed in todays Summit, to come up with a release plan that works for > most of us, I’d l

"F2F" (well, online) working group for a release schedule proposal

Hi all, As discussed in todays Summit, to come up with a release plan that works for most of us, I’d like to have a “F2F" (online) with representatives from any organization / team that is interested in the upcoming releases. The goal would be to have an inclusive, but not too large, working gr

Re: [VOTE] Release Apache Traffic Server 8.1.3 (RC1)

+1 — leif > On Nov 1, 2021, at 3:49 PM, Bryan Call wrote: > > I've prepared a release for 8.1.3. The release notes are available at: > > > https://github.com/apache/trafficserver/pulls?q=is%3Aclosed+is%3Apr+milestone%3A8.1.3 > >

Re: [VOTE] Release Apache Traffic Server 9.1.1 (RC2)

+1 — leif > On Nov 1, 2021, at 3:49 PM, Bryan Call wrote: > > I've prepared a release for 9.1.1. The release notes are available at: > > > https://github.com/apache/trafficserver/pulls?q=is%3Aclosed+is%3Apr+milestone%3A9.1.1 > >

Re: [API] Integration of libswoc

> On Oct 13, 2021, at 9:08 AM, Alan M. Carroll wrote: > > Libswoc (https://github.com/solidwallofcode/libswoc), "Solid Wall Of C++" > library, is a collection of C++ utility classes. They are based on existing > ATS core classes, except for Lexicon. Documentation is available here - > http:

Re: [DISCUSS] Promote or deprecate experimental API TSHttpTxnCntl()

Anyone have any thoughts on this? If not, lazy consensus will apply and I’ll pick one (which would be to promote TSHttpTxnCntl() and deprecate the overlapping APIs). — Leif > On Oct 5, 2021, at 7:40 AM, Leif Hedstrom wrote: > > Hi all, > > While poking around, looking for a

Re: [VOTE] new API for getting the SNI for a client connection

> On Oct 7, 2021, at 1:54 AM, Masakazu Kitajo wrote: > > I'm +1 on adding it, but not sure about the name. > > There are a couple of similar APIs such as TSVConnSslCipherGet and > TSVConnSslProtocolGet, and those start with "TSVConnSsl". TSVConnSslSNIGet > may be more consistent with existing

Re: [VOTE] new API for getting the SNI for a client connection

+1. I think the same pattern is in a couple of other “example” plugins as well, which could be cleaned up the same way. — Leif > On Oct 5, 2021, at 11:02 AM, Randall Meyer > wrote: > > Hello! > I'd like to propose adding a new API get grab the SNI from the client > connection. > > const

[DISCUSS] Promote or deprecate experimental API TSHttpTxnCntl()

Hi all, While poking around, looking for a way to turn off logging for a single transaction (to effectively sample logging activity), I stumbled upon this API in experimental.h: tsapi TSReturnCode TSHttpTxnCntl(TSHttpTxn txnp, TSHttpCntlType cntl, void *data); The intent here was obviously t

Re: Branching v9.2.x on Monday 9/20/2021

e frames more accurately. Cheers, — Leif > > Masakazu > > > On Wed, Sep 29, 2021 at 2:01 PM Leif Hedstrom wrote: > >> Well, we shouldn’t merge PRs to master which are not properly reviewed. If >> the consensus is that we stop merging on master until 9.2.x is sta

Re: Branching v9.2.x on Monday 9/20/2021

es on 9.2, and I'm going to review > only those PRs until we release 9.2.0. > > If any of you wanted to annoy RM like we did for 9.1.0 release, request > reviews from someone else ;-) > > Masakazu > >> On Wed, Sep 29, 2021 at 7:31 AM Leif Hedstrom wrote: &g

Re: Branching v9.2.x on Monday 9/20/2021

e invasive / incompatible PRs that we want for 10.0.0, but which can not go into 9.x. Cheers, — Leif > > Masakazu > > On Sat, Sep 18, 2021 at 1:52 AM Leif Hedstrom wrote: > >> Hi all, >> >> I’m going to branch v9.2.x, from current master, Monday morning, 9/20.

Re: [DISCUSS] Removing the INKUDP* APIs

> On Sep 28, 2021, at 11:19 AM, Randall Meyer > wrote: > > I agree with Masakazu and am +1 for removing these APIs. +1 — Leif

Branching v9.2.x on Monday 9/20/2021

Hi all, I’m going to branch v9.2.x, from current master, Monday morning, 9/20. We will continue development on v9.2.0 of course, but remember that you will need to mark PRs with “Project 9.2.x” for consideration into the upcoming branch. I’d like to aim to have a v9.2.0 release either late Nove

Re: [VOTE] Release Apache Traffic Server 9.1.0 (RC0)

6:35 PM Randall Meyer > wrote: > +1 > > Built on macOS, tests passed. On Tuesday, August 10, 2021, 12:11:52 PM > PDT, Leif Hedstrom mailto:zw...@apache.org>> wrote: > > I've prepared a release for 9.1.0 (RC0), which is both a new feature and bug > fix rele

Re: [VOTE] Release Apache Traffic Server 9.1.0 (RC0)

And +1 from me obviously. — Leif > On Aug 13, 2021, at 15:29, Bryan Call wrote: > > +1 - Tested on Fedora 34 and passed all test. We are running 9.1.0 in > production with a few local patches to test upcoming features. > > -Bryan > > >> On Aug 10, 2021, at

[VOTE] Release Apache Traffic Server 9.1.0 (RC0)

I've prepared a release for 9.1.0 (RC0), which is both a new feature and bug fix release. This release of v9.1.0 is backwards compatible with all v9.0.x releases. The intent is that v9.1.x will replace the previous v9.0.x release once it’s released and deemed stable. For a list of all PRs in thi

[DISCUSS] Next 9.x release

Hi all, Now with v9.0.2 being released, I’d like to focus our efforts on the v9.1.0 release. With that in mind: * Only mark PRs for “Project 9.0.x” if they are either critical crashers, complete failed expected behavior, or a CVE level security issue. * With v9.1.0 being imminent, only mark “Pr

Re: [VOTE] Release Apache Traffic server 8.1.2 (RC0)

+1 — Leif > On Jun 23, 2021, at 12:22 PM, Evan Zelkowitz wrote: > > Ive prepared a release for 8.1.2 (RC0), which is a bug fix release. For a > list of all PRs, see > >https://github.com/apache/trafficserver/milestone/47?closed=1 >

Re: [VOTE] Release Apache Traffic Server 9.0.2 (RC0)

+1 obviously, we’re running with many of these fixes in our test deployments. — Leif > On Jun 22, 2021, at 9:35 AM, Leif Hedstrom wrote: > > I've prepared a release for 9.0.2 (RC0), which is a bug fix release. For a > list of all PRs, see > > https://github.c

[VOTE] Release Apache Traffic Server 9.0.2 (RC0)

I've prepared a release for 9.0.2 (RC0), which is a bug fix release. For a list of all PRs, see https://github.com/apache/trafficserver/milestone/48?closed=1 or for a brief ChangeLog (also attached below): https://github.com/apache/trafficserver/blob/9.0.x/CHANGELOG-9.0.2 Thi

Re: [E] Is there a performance issue with --enable-debug binaries?

> On Apr 20, 2021, at 5:55 PM, Walt Karas > wrote: > > --enable-debug means that the code will be compiled without the -O3 option, > that is to say, no optimization. It's not related to whether trace/debug > output is configured on or off. You can enable trace/debug output even if > you did

[ANNOUNCE] Apache Traffic Server v9.0.1 is Released!

Apache Traffic Server v9.0.1 Released The Apache Software Foundation and the Apache Traffic Server (ATS) project are pleased to announce the release of Apache Traffic Server v9.0.1! ATS is a high performance, scalable HTTP Intermediary and proxy cache. It is used by several large internet servi

Re: [VOTE] Release Apache Traffic Server 9.0.1 (RC1)

Calling this vote with 5 +1’s and no -1’s. I’ll move the artifacts to the download site now, and will send out the announcement tomorrow. Thanks everyone for voting. — Leif > On Apr 10, 2021, at 4:21 PM, Leif Hedstrom wrote: > > I've prepared a another release for 9.0.1 (RC

Re: [VOTE] Release Apache Traffic Server 9.0.1 (RC1)

+1 — Leif > On Apr 10, 2021, at 16:22, Leif Hedstrom wrote: > > I've prepared a another release for 9.0.1 (RC1), which is a bug fix release > only. For a list of all PRs, see > >https://github.com/apache/trafficserver/milestone/31?closed=1 > > >

[VOTE] Release Apache Traffic Server 9.0.1 (RC1)

I've prepared a another release for 9.0.1 (RC1), which is a bug fix release only. For a list of all PRs, see https://github.com/apache/trafficserver/milestone/31?closed=1 or for a brief ChangeLog (also attached below): https://github.com/apache/trafficserver/blob/9.0.x/CHANGELO

  1   2   3   4   5   6   7   8   9   10   >