Re: Remove t3c (nee ORT) dispersion?

+1 On Aug 12, 2021, 5:33 PM -0400, John Rushford , wrote: > +1 > > Sent from my iPhone > > > On Aug 12, 2021, at 2:46 PM, ocket wrote: > > > > +1 that sounds much simpler > > > > > On Thu, Aug 12, 2021 at 10:15 AM Robert O Butts wrote: > > > > > > I'd like to propose we remove the t3c (nee O

Re: Replace Riak w/ PostgreSQL

+1 On Dec 7, 2020, 5:58 PM -0500, Rawlin Peters , wrote: > Yes, I agree with the plugin interface as well, but that is what I was > hoping to defer to a follow-up thread, preferably with a rough draft > of a blueprint in hand. First, I just want to get an official > consensus on PostgreSQL (in this

Re: ORT Rewrite Proposal

I’m +1 on all of these. Unsure about package control, though. I suspect that there are still some people using that one out in the world. I’ve never once heard of interactive mode being used, I like report mode but I’m fine as long as there’s an alternative. Agree about reval mode. It was made

Re: Feature Proposal: Server Capabilities

I love this. +1 On Wed, Oct 9, 2019 at 12:46 PM Robert Butts wrote: > Hi all! We have a proposal for a new feature for TC: Server Capabilities. > > Blueprint is here: https://github.com/apache/trafficcontrol/pull/3972 > > In a nutshell, the problem we're solving is that it's impossible to only >

Re: Cache-Side Config Generation

20-30% of the entire config code. >>>> >>>>> What I AM nervous about is someone rewriting all that code >>>> I agree, there's some inevitable risk involved. FWIW I've gone to great >>>> lengths to minimize the risk as much as possible

Re: Cache-Side Config Generation

This is probably a stupid question, but is there any reason we can't hit the DB from ORT, thus saving us the expense of writing any new scripting? My understanding is that the biggest hit on traffic ops isn't the DB so much as the perl processing for thousands of hosts at once. I assume that t

Re: Release 3.1 vs. Release 4.0

Let's do this thing, then. Milestone 3.1 is on git. Please place issues that are desired to be merged into this release there. https://github.com/apache/trafficcontrol/milestone/6 Derek > On Jul 27, 2019, at 8:13 AM, Steve Malenfant wro

Re: [EXTERNAL] Re: Integration with LetsEncrypt needs TR updates / automatic Snapshot

l be as >>>> easy as Rob thinks - well, `/snapshot` would be, but I think >>>> `/snapshot/new` will be significantly >>>> more involved. >>>> >>>> As far as ACME challenges go, we could build a client into TR, so that >> the

Re: Integration with LetsEncrypt needs TR updates / automatic Snapshot

This was my suggestion when discussed on slack earlier as well. Probably the easiest to implement though I think Rob's suggestion also had merit. I'm -1 on anything that auto snaps, and LE can't really wait around for a user snap. On Tue, May 7, 2019 at 7:29 PM Rawlin Peters wrote: > Putting th

Re: Deprecate STEERING in favor of CLIENT_STEERING

I'm definitely +1 on this. Good idea! > On May 2, 2019, at 9:32 AM, Jeremy Mitchell wrote: > > Good suggestion, Rawlin. > > +1 I'm always in favor of any sort of simplification and this sounds like a > good one. As always, I'd suggest creating an issue ( > https://github.com/apache/trafficcont

[VOTE] Release Apache Traffic Control 3.0.1-RC1

D5&op=vindex Make sure you refresh from a key server to get all relevant signatures. The source .tgz file, pgp signature (.asc signed with my key from above), and sha512 checksums are provided here: https://dist.apache.org/repos/dist/dev/trafficcontrol/3.0.1/RC1 Thanks! Derek Gelinas