Yeah, we used to have astats separate, but during upgrades, we had to
carefully keep track of which astats were compatible with which ATS.
It was easier to just combine them. We use this snippet in our build
script:
# Patch astats in so that it builds in-tree.
cp -far /opt/src/astats_over_http
/rp
Thanks for comments Chris, I agree with all of them.
Do you typically include astats in your traffic server tar balls? Based on
whats in Github, its traditionally been shipped as a separate RPM.
I agree build would be simpler with astats packaged in, especially because the
TS version dependenc
I have so many thoughts on this topic. :)
We use a tool for composing the public ATS build on top of our list of
backports (all of which are currently public, iirc). This is how we
use stuff like URI Signing, which isn't available in ATS 7. I'm
currently in the process of getting that opened up so
I like the idea and looks good. One thing to think about though is in
the trafficserver.spec file, if there are any good ways to dynamically do those
config files includes at the end. Im no spec expert so Im not sure if there may
be a better way but recently here I worked on getting our
I’ve opened a PR to produce Trafficserver and astats RPMs in the Traffic
Control build process. Previously, new users would need to create their own
build environments or ask for RPMS on Slack.
This PR will lower the barrier to entry for new users. For more involved users,
theres now a set of s
