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 dependencies is some of the most complicated of my changes. If you get TSB open, is there a commitment to maintaining an up to date list of patches that should be applied for full ATC compatibility (today just URI signing/astats)? —Eric > On Jun 15, 2018, at 4:03 PM, Chris Lemmons <alfic...@gmail.com> wrote: > > 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 that everyone > can look at it (a couple weeks, probably, though), but the principle > behind it isn't exceptionally complex. > > What I'd like to see in the ATC ATS RPM is: > - It's deterministically produced (basically, everything (as far as > is reasonable) pegged to specific changesets/versions). > - It contains every feature supported by ATC. > - It builds as a `./pkg` target: `./pkg ats_build`. > - It produces a single RPM that just works. > Bonus points if it's relatively easy to add extra backports or private > bug fixes. > > The PR is close on determinism, though it encourages using a branch > instead of a revision, which could cause trouble for folks with RPMs > updating unexpectedly. It doesn't have backports for URI Signing and > astats is in its own RPM, which I think puts more work on the people > managing the CDN than is necessary. It's spot on for the ./pkg usage. > > It's absolutely a step in the right direction, though, and I'd rather > have something than nothing. I'm not totally enthused with this > solution, but it's a start and we can work toward things going > forward. > > On Fri, Jun 15, 2018 at 12:48 PM, Zelkowitz, Evan > <evan_zelkow...@comcast.com> wrote: >> 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 internal >> spec and build system to be able to do builds of ATS master and it looks >> like starting with 8/9 some more of those files will be going away and >> another new one introduced. So those files change frequently across version >> numbers >> >> On 6/15/18, 11:27 AM, "Eric Friedrich (efriedri)" >> <efrie...@cisco.com.INVALID> wrote: >> >> 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 scripts that will build inside a Dockerized >> Jenkins environment. >> >> The changes rely on having all TS changes in a single git repository to >> form the RPM source tarball. I understand there are some users which have >> private tooling to build from multiple repos. I’m open to including this if >> possible. Until that tool gets open sourced, I think this is a step forward >> for TC builds. >> >> https://github.com/apache/trafficcontrol/pull/2399 >> >> Any concerns with bringing this in? >> >> —Eric >> >> >>
