F42 Change Proposal: Trafficserver 10.0 (self-contained)

Project Discussion Change Proposals
,
1

:link: Trafficserver 10.0

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

Summary

Upgrade Apache Traffic Server in Fedora to version 10.0.

:link: Owner

:link: Detailed Description

Apache Traffic Server in Fedora will be upgraded to v10.0.

More details on Traffic Server 10.x are available from the upstream What’s New page. Notably, there is a breaking change in configuration file format, as ATS 10.x changes records.conf to records.yaml and does not support the previous configuration format. Many additional parameter changes and removals are also documented in the upstream Upgrading page.

:link: Feedback

:link: Benefit to Fedora

Fedora includes the latest version of ATS, which will also be proposed for EPEL 10.

:link: Scope

  • Proposal owners:
    • Upgrade trafficserver package to 10.x
    • DIscuss proprietary of running convert2yaml.py on records.config as part of post-install script

:link: Upgrade/compatibility impact

Users will be upgraded to Traffic Server 10.x. Daemon will not start until records.config is updated to records.yaml.

:link: How To Test

Install package, or upgrade from older release. Configure, or update configuration, then verify operation.

:link: User Experience

The user must update records.config to records.yaml before trafficserver will restart after upgrade.

Alternatively, this could be triggered as a post-install scriptlet. In most cases the daemon would run normally after upgrade, as long as no removed features are in use (see upstream documentation).

:link: Dependencies

None outside of this Change.

:link: Contingency Plan

  • Contingency mechanism: Roll back the trafficserver packages.
  • Contingency deadline: Beta freeze
  • Blocks release? No.

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

Apache Traffic Server (trafficserver) in Fedora has been upgraded to version 10.x. This introduces a breaking configuration change where records.config must be updated to records.yaml. Additional upgrade steps may be required if removed features or APIs are in use; please review the upstream documentation at Upgrading to ATS v10.x — Apache Traffic Server documentation

Last edited by @amoloney 2025-01-15T23:46:08Z

Last edited by @amoloney 2025-01-15T23:46:08Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I’d particularly appreciate opinions on this (typos corrected):

If this is not done by the %post scriptlet, the trafficserver unit will fail on an upgrade to 10.x, which seems less than ideal. On the other hand, if a no-longer-supported feature is used, even with an automatic update the unit will fail (but this is far less likely).

Is there general Fedora guidance on such things?

4

I don’t think there’s a absolute guideline here. I think it depends.

Can the convert2yaml.py fail? Are all the python deps for it present?

When trafficserver fails to start due to old config, what message(s) does it output?

My personal feeling is that it would be ok to run the script only if it’s very simple and unlikely to fail. It should also save off a copy of the old config for reference.

5

Here is the convert2yaml.py script for reference: trafficserver/tools/records/convert2yaml.py at master · apache/trafficserver · GitHub

I have added the dependencies for the script to the package Requires, so that should not be an issue.

Software can always fail. :slight_smile: I do not expect it would fail to produce output on a valid (existing) input. However, I do not think that the output will always be 100% complete; several config options have been renamed and others have been removed, and while these will be converted to be syntactically correct in the new YAML format, the application may still fail to start or behave in a different manner. (I don’t entirely agree with how this was done, but that’s a separate discussion.)

If the old config file exists, this will cause the software to state:

traffic_server WARNING: **** Found a legacy config file (/your/ats/records.config). Please remove it and migrate to the new YAML format before continuing. ****

I absolutely intend to save the old config (as records.config.orig) if this runs as part of the post scriptlet.

6

Here is the convert2yaml.py script for reference: trafficserver/tools/records/convert2yaml.py at master · apache/trafficserver · GitHub

I have added the dependencies for the script to the package Requires, so that should not be an issue.

Figured, but I thought I would ask. :wink:

Software can always fail. :slight_smile: I do not expect it would fail to produce output on a valid (existing) input. However, I do not think that the output will always be 100% complete; several config options have been renamed and others have been removed, and while these will be converted to be syntactically correct in the new YAML format, the application may still fail to start or behave in a different manner. (I don’t entirely agree with how this was done, but that’s a separate discussion.)

If the old config file exists, this will cause the software to state:

traffic_server WARNING: **** Found a legacy config file (/your/ats/records.config). Please remove it and migrate to the new YAML format before continuing. ****

I absolutely intend to save the old config (as records.config.orig) if this runs as part of the post scriptlet.

ok. Perhaps it would be worth doing the scriptlet for now, and watch for
bug reports. If something broke, you could revert before release.
(Or fix whatever it is).

7

WFM. Honestly, I don’t think there’s more than two or three other users of this package than me, and I use it in EPEL. (Do we have telemetry on this?)

8

Nope. It’s not possible to know how many users install some particular
package (since they could install from any mirror we don’t control, or
download and copy the rpm or …)