Re: astats counters

One thing to note with astats is that all out_bytes and in_bytes stats count only the response body, not the headers. Conversely, the ATS logs on disk will count both the headers and the response body. -- Thanks, Jeff On Tue, Jan 24, 2017 at 11:26 AM, Dave Neuman wrote: > Hi

Re: Backup Cache Group Selection

the coordinate to match the us-ca-sandiego group in the CZF >> and now the request is sent to the us-ca-sandiego caches : >> 1485523546.345 qtype=HTTP chi=24.252.192.1 url=" >> http://crs.cox-col-jitp2.cdn1.coxlab.net/; cqhm=GET cqhv=HTTP/1.1 rtype=CZ >> rloc="32.72,-11

Re: Backup Cache Group Selection

;:"-83.6865"},"locationByFederation":"not >> found","requestIp":"24.252.192.0","locationByCoverageZone":"not found"} >> > I believe I'm expecting "locationByCoverageZone" to find something... > > I tried

Re: Backup Cache Group Selection

the next closest > cache group? > >> On Jan 4, 2017, at 11:25 AM, Eric Friedrich (efriedri) <efrie...@cisco.com> >> wrote: >> >> >> On Jan 3, 2017, at 5:20 PM, Jeff Elsloo >> <jeff.els...@gmail.com<mailto:jeff.els...@gmail.com>>

Re: Backup Cache Group Selection

Hey Eric, It sounds like the use case you're after is an RFC 1918 client associated with a cache group whose caches are all unavailable for one reason or another. Is that correct? I looked at the code a bit, and I think that we can make a minor change to achieve the behavior you're looking for

Re: Backup Cache Group Selection

settings on Ops. Is this > expected behavior? > > Thanks, > John > > > On 27/01/2017, 10:51 PM, "Jeff Elsloo" <jeff.els...@gmail.com> wrote: > > Steve: I don't think the patch is required, however, as Eric found, > without the patch there co

Re: Backup Cache Group Selection

the source, but the coordinates from > the TO DB are used for the various candidate cache groups), and the fact > that there is a 'duplication'. > > Is this description true ? > > > > On Wed, Mar 29, 2017 at 7:02 PM, Jeff Elsloo <els...@apache.org> wrote: > > >

Re: Public CI Builds for Traffic Control

Docker isn't required to build the software, it's just another option. There's a build script, `build/build.sh`, that works just fine so long as you have the dependencies required to successfully build all components. I only mention this because if Docker is going to gate our ability to perform CI

Re: Traffic Router Cors

Can you be more specific on what specifically you would like to accomplish? -- Thanks, Jeff On Mon, Apr 3, 2017 at 5:42 AM, Burak Sarp wrote: > Hi all, > Is there any way to disable cors on Traffic Router? > thanks,sarp

Traffic Router Multi-Location/Client Steering Feature

Hi all, We've been working on a new feature for Traffic Router that will add support for providing multiple locations in the response to a client for HTTP delivery services. Phil has proposed a spec for the response format, which is roughly comprised of the following: 1) 302 redirect 2) Location

Re: Adding support for per-DeliveryService routing names

Rawlin, That sounds like a solid plan, however, keep in mind that although it's unlikely, we may have users that have elected to change the default routing name for DNS delivery services. Thus, step 2 should not be run as defined, and steps 3 and 4 should be applied to the DNS routing name case

[ANNOUNCE] Apache Traffic Control Traffic Router Slowloris Denial of Service Vulnerability - CVE-2017-7670

CVE-2017-7670: Apache Traffic Control Traffic Router Slowloris Denial of Service Vulnerability Severity: High Vendor: The Apache Software Foundation Versions Affected: Traffic Control 1.8.0 Traffic Control 2.0.0 RC0 The unsupported Traffic Control 1.5.x, 1.6.x, and 1.7.x versions may be also

Re: Obsolete Traffic Ops API endpoint removal

+1 on removing the route. I would like to see our downstream components migrate to something different than the giant monolithic JSON configuration instead of moving to this new endpoint which is essentially the same format minus some key information. I agree with what Rob said; it was an

Re: traffic_router tomcat init script (shutdown) problems

I discussed this with Jason, reviewed the PR and will be merging it soon unless someone has concerns. I asked specifically about "force" being the default shutdown mode, and that was done intentionally. There might be a use case for a graceful shutdown with typical applications deployed into

Promote Golang Traffic Monitor to Default

Hi all, We currently have two versions of Traffic Monitor: Java and golang. When we build all components, as far as I know, it results in a race condition between the two, as the resulting RPMs have the same filename. A PR[1] was opened to address the issue and the approach was to add `_go` to

Re: Promote Golang Traffic Monitor to Default

quired version of Traffic Router to use the Golang TM? > - I know Golang TMs can gossip with Java TMs, but can we mix versions here > too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)? > > —Eric > > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <els...@apache.org> wrote: >&g

Re: Traffic Ops Golang Migration Proposal

I'm +1 on most of what you suggest, except for doing the takeover in postinstall in traffic_ops. While we can do whatever we want with postinstall, I think it's awkward to have a tool within the traffic_ops package configuring something under the traffic_ops_golang package, when the latter

Re: Promote Golang Traffic Monitor to Default

t; On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson <dewr...@gmail.com> >> wrote: >> >> > When: Read · Mon, Jul 17. >> > <https://timyo.com/?utm_source=expectationheader_medium=email> >> > [image: Timyo expectation line] >> > +1 >>

Re: Traffic Ops Golang Migration Proposal

does require it for the migrated endpoints. > > I agree with moving away from manual post-installation scripts, but I don't > think we can avoid it here, because we need the user to set a new port. > > > On Wed, Jul 19, 2017 at 11:40 AM, Jeff Elsloo <els...@apache.org

Re: Edge Server throughput measure

Hi, Could you be a little more specific? We use Traffic Monitor to keep track of edge cache performance and it implements what we call the health protocol. The health protocol determines which caches are eligible to receive traffic based on configurable thresholds. Traffic Router is a consumer of

Re: CCR A record TTL parameter changes is not reflected in CRConfig.json

Hey Ori, I believe the delivery service specific TTL setting issue you describe is a bug. We haven't been on 1.7 for some time, but to the best of my knowledge it's still an issue. TC-200 and TC-254 document the issue. We're at the Traffic Control summit now, and will be doing a bug scrub later

Re: Using a full-chain SSL certificate For a Delivery Service.

It should be noted that you might need to use an external tool of some sort to order and verify the certificate chain properly. I believe that's what we did when we ran into the problem. -- Thanks, Jeff On Tue, May 23, 2017 at 10:05 AM, Jason Tucker wrote: > +1 to what

Re: TC Contributers to Publish list of Planned/WIP Items for Better Community Sync

Dave sort of implied this already, but in my opinion, we should only use GitHub for the roadmap items if we move all issues there, which will require a vote separate from the roadmap discussion. This makes it more than simply adding a few roadmap items to our project on GitHub, as we have a lot of

Re: [VOTE] Move Traffic Control to full GitHub

+1 on moving. -- Thanks, Jeff On Thu, May 18, 2017 at 2:40 PM, Dan Kirkwood wrote: > +1 > > On Thu, May 18, 2017 at 2:32 PM, Jan van Doorn wrote: >> In >>

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC3)

+1 on this, signature and hashes validate. -- Thanks, Jeff On Mon, Jun 5, 2017 at 7:03 AM, Eric Friedrich (efriedri) wrote: > Hello All, > > I've prepared the next candidate release for incubator-trafficcontrol v2.0.0 > (RC3) > > Changes since 1.8.0: >

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC2)

I'm +1 on this. Thanks for creating the RC Eric! -- Thanks, Jeff On Thu, Jun 1, 2017 at 9:30 AM, Eric Friedrich (efriedri) wrote: > Hello All, > > I've prepared the next candidate release for incubator-trafficcontrol v2.0.0 > (RC2) > > Changes since 1.8.0: >

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC4)

+1 again. Signature and hashes validate. -- Thanks, Jeff On Mon, Jun 5, 2017 at 12:16 PM, Eric Friedrich (efriedri) wrote: > Hello All, > > I've prepared the next candidate release for incubator-trafficcontrol v2.0.0 > (RC4) > > Changes since 1.8.0: >

Re: [VOTE] Release Apache Traffic Control 1.8.1-incubating (RC0)

I'm +1 on this. Thanks for preparing the RC Dan! -- Thanks, Jeff On Wed, May 31, 2017 at 4:30 PM, Dan Kirkwood wrote: > Hello All, > > I've prepared the first candidate release for incubator-trafficcontrol > v1.8.1 (RC0) > > Changes since 1.8.0: >

Re: DNSSEC in Traffic Router

Hey Amir, The DNSSEC setup is not delivery service specific, but CDN specific. Once enabled, it will generate signatures for *all* DNS records for which the Traffic Routers are authoritative. There are no delivery service specific settings. The big thing to understand is the relationship between

Re: Preventing routing to individual caches

CCR_IGNORE won't work, and a quick grep in the code base makes me think CCR_IGNORE won't even work as it did previously (drop hosts from the CRConfig). That said, it's a good idea and I think we might be able to use the same concept to accomplish this, as long as we make Traffic Ops, or Traffic

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC6

+1 Signature validates and tests performed previously were unaffected by the latest RC. -- Thanks, Jeff On Fri, May 11, 2018 at 12:22 PM, Robert Butts wrote: > Hello All, > > I've prepared a release for v2.2.0-RC6 > > The vote is open for at least 72 hours and passes if a

Re: Anonymous IP Blocking Flowchart

Hey Eric, Thanks for sending this out. Hopefully we can build more of these diagrams in the future to include in the docs. I'll try to put something similar together for the stuff I've been working on. -- Thanks, Jeff On Thu, Oct 19, 2017 at 1:55 PM, Eric Friedrich (efriedri)

Re: Promote Golang Traffic Monitor to Default

conservative, we could keep both with the renamed structure for 2.2, and remove the Java version in 2.3. This is the direction I'm leaning, though I'd like to hear from interested parties first. Thoughts? -- Thanks, Jeff On Mon, Jul 24, 2017 at 8:23 AM, Jeff Elsloo <els...@apache.org> wrote: >

Re: Golang Proxy Validation Dependencies

I don't think we should assume anything about the performance just because it uses reflection. Yes, traditionally reflection is computationally expensive, however, when used properly the penalty can be negligible. I don't think we have enough understanding of these libraries to know whether there

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC0

-1 due to the following PR breaking the Traffic Router build: https://github.com/apache/incubator-trafficcontrol/pull/1720 I'm looking into the issue now and hope to have it resolved soon. -- Thanks, Jeff On Tue, Feb 13, 2018 at 11:56 AM, Robert Butts wrote: > Hello All, > >

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC0

I just submitted the following PR to resolve the issues stemming from PR 1720: https://github.com/apache/incubator-trafficcontrol/pull/1877 -- Thanks, Jeff On Tue, Feb 13, 2018 at 3:25 PM, Jeff Elsloo <els...@apache.org> wrote: > -1 due to the following PR breaking the Traffic Rou

Re: Traffic Router Enhancement - Default Maxmind Geolocation Override

Unless there are objections, I will be merging this PR (#1866) in the near future. Please speak up now if you have any concerns. -- Thanks, Jeff On Mon, Feb 19, 2018 at 10:24 AM, Rivas, Jesse wrote: > Nir, > > I'm not familiar with the behavior of other geo DBs

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC4

+1 Tested: -`./pkg` - signatures validate - upgrade of Traffic Router works without issue -- Thanks, Jeff On Fri, Apr 13, 2018 at 10:26 AM, Dan Kirkwood wrote: > +1 > > I tested: > - signature and checksum good > - `./pkg -v` builds all components successfully > -

Re: [VOTE] Resolution for Traffic Control graduation to TLP

gt;> > the projects within the scope of responsibility of the Apache Traffic >> > Control Project; and be it further >> > >> > RESOLVED, that the persons listed immediately below be and hereby are >> > appointed to serve as the initial members of the Apache Tr