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 as
networkNode.getLoc() returns the name of the cache group in the CZF
that the IP falls under.
--
Thanks,
Jeff
On Wed, Jan 4, 2017 at 9:25 AM, Eric Friedrich (efriedri)
wrote:
>
> On Jan 3, 2017, at 5:20 PM, Jeff Elsloo
> mailto:jeff.els...@gmail.com>> wrote:
>
> Hey Eric,
&
> cache group?
>
>> On Jan 4, 2017, at 11:25 AM, Eric Friedrich (efriedri)
>> wrote:
>>
>>
>> On Jan 3, 2017, at 5:20 PM, Jeff Elsloo
>> mailto:jeff.els...@gmail.com>> wrote:
>>
>> Hey Eric,
>>
>> It sounds like the use case
": [
>> ...
>> ],
>> "network": [
>> ...
>> ],
>> "coordinates": {
>> "longitude": “-75.3342",
>> "latitude": “42.555"
>> }
>&
5"},"locationByFederation":"not
>> found","requestIp":"24.252.192.0","locationByCoverageZone":"not found"}
>>
> I believe I'm expecting "locationByCoverageZone" to find something...
>
> I tried o
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 Adan,
> I answered i
a request through Traffic Router directly using
the X-MM-Client-IP header, or fakeClientIpAddress query parameter
using the example IP of 24.252.192.0? After you do so, check the
coordinates in the log entry and see if the result is a CZ hit.
--
Thanks,
Jeff
On Thu, Jan 26, 2017 at 2:03 PM, Jeff Els
he 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,-117.08" rd
Can we open up the permissions on the spreadsheet so we can sign up? :)
--
Thanks,
Jeff
On Tue, Feb 7, 2017 at 4:54 PM, Jan van Doorn wrote:
> See below.
>
> We were unable to do this on Monday and Tuesday, so the Traffic Server /
> Traffic Control combined summit is on Sunday 5/14 and Monday 5
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
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
from CG settings on Ops. Is this
> expected behavior?
>
> Thanks,
> John
>
>
> On 27/01/2017, 10:51 PM, "Jeff Elsloo" wrote:
>
> Steve: I don't think the patch is required, however, as Eric found,
> without the patch there could be some gaps
oid inconsistent config for lat/long.
>
> Thanks,
> John
>
> ---Original---
> From: "Jeff Elsloo "
> Date: 2017/3/29 22:45:12
> To:
> "dev@trafficcontrol.incubator.apache.org";
> Subject: Re: Backup Cache Group Selection
>
> Yes, it
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 wrote:
>
> > The cachegroup settings in the Traffic Ops GUI end up in the
>
he cache’s as configuration in Traffic Op’s CG record?
>
> —Eric
>
>
>> On Mar 30, 2017, at 1:07 PM, Jeff Elsloo wrote:
>>
>> It could now be considered the "average" of the location of the
>> clients within that section of the CZF, however, it shou
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
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
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 to
+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
>> https://lists.apache.org/thread.html/5bdb9b073343f49c1d5b85147eb9d260bf7ad15d61384929993c7e1d@%3Cdev.trafficcontrol.apache.org%3E
>> Dave
>>
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 Dave said. A full cert cha
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
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:
> https://github.com/apache/incubator-trafficcontr
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:
> https://github.com/apache/incubator-
We use LDAP all the time. It's optional of course, but in our
deployment nobody should be using local accounts unless they're not in
LDAP for some reason (external users, portal users, etc).
Application/API accounts could go either way, but users of the TO UI
should use LDAP whenever possible to av
+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:
> https://github.com/apache/incubator-traffi
+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:
> https://github.com/apache/incubator-traffic
+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 incomplet
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 aff
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 Tomcat
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 the
on 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 wrote:
>>
>> Hi all,
>>
>>
Thanks for volunteering, Hank!
--
Thanks,
Jeff
On Mon, Jul 17, 2017 at 2:19 PM, Dave Neuman wrote:
> Awesome, thanks Hank!
> Now that we have a RM, I think we can start the conversation of when to
> branch. For your first task as RM do you want to do that, or do you want
> me to?
> Thanks,
> Da
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
package
lly 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 wrote:
>>
>&g
ne Richardson
>> wrote:
>>
>> > When: Read · Mon, Jul 17.
>> > <https://timyo.com/?utm_source=expectationheader&utm_medium=email>
>> > [image: Timyo expectation line]
>> > +1
>> >
>> > On Fri, Jul 14, 2017 at 2:49 PM, Je
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 in
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 Mon
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
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)
wrote:
> Just real
to be more
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 wrote:
> It sou
lease as a liability. Old TM should be adjusted to the
> changes and tested regularly.
> So in this case, if there are no automated tests to cover its
> functionality, I would suggest to remove Java TM from the code base.
>
> Nir
>
> On Mon, Oct 23, 2017 at 5:58 PM, Jeff Elsloo
I think this discussion has drifted far from Dylan's original intent,
which is to set a reasonable default in the short term. We can argue
about what the default is, but ultimately the real way to fix this is
to ensure that we follow the RFCs. If a resolver cannot switch to TCP,
we can truncate the
21 PM, Volz, Dylan wrote:
>
>> Based on the discussion we will be changing the schema default from 0 to 5
>> for now;
>> with the knowledge that this is a complex issue that could benefit from
>> ensuring we
>> are following the relevant RFCs and perhaps a configur
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 i
-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,
>
> I've prepared a rel
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 wrote:
> -1 due to the following PR breaking the Traffic Router build:
> https://gith
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 concerning default
> locations, b
he person holding such office to serve at the
>> > direction of the Board of Directors as the chair of the Apache Traffic
>> > Control Project, and to have primary responsibility for management of
>> > the projects within the scope of responsibility of the Ap
+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
> - traffic_ops installs on
+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 majority of at least
>
50 matches
Mail list logo
