Re: astats counters

[Jeff Elsloo]

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 inline based on my understand of astats, if I am wrong,
> hopefully someone will correct me.
> Thanks,
> Dave
>
> On Tue, Jan 24, 2017 at 1:40 AM, Adan Alper  wrote:
>
>> Hello,
>>
>>
>>
>> First of all thanks for the previous replies they were very helpful.
>>
>>
>>
>> We currently have a running cache that knows how to read remap rules from
>> traffic ops, acquire, deliver and export a stats file (currently with dummy
>> values) to traffic monitor.
>>
>> My question is regarding some of the astat counters definitions.
>>
>> What is the definition of the following counters:
>>
>> 1.   plugin.remap_stats.delivery-service-fqdn.in_bytes – What is the
>> definition of in_bytes? Bytes from client or from origin server?
>>
>
> -- in_bytes are bytes received by the server.  This can be from a client
> (request) or an org server (content).
>
>
>> 2.   plugin.remap_stats.delivery-service-fqdn.out_bytes – What is the
>> definition of out_bytes? Bytes sent to client?
>>
> -- out_bytes are bytes sent by the server, this can be to a client
> (content) or org (request)
>
>>
>> 3.   plugin.remap_stats.delivery-service-fqdn.statusXXX – Does this
>> count the status sent to client or received by origin server?
>>
> -- This is the status sent to the client. I believe if a cache receives a
> 5xx from an upstream server, like an origin, it will pass it along and this
> counter will be updated, but I could be wrong.
>
>>
>> 4.   configReloadRequests, lastReloadRequest, configReloads – Do these
>> counters count ATS reloads or configuration updates? Are these counters
>> important for traffic monitor or just for debug?
>>
>
> -- I am not sure about this one.  If I was to guess I would guess it was
> for ATS config reloads.  This is not used by TM afaik.
>
>
>
>> 5.   astatsLoad – Time astats file was last updated?
>>
>
> -- again, not sure, but I would guess it is the timestamp that the astats
> plugin was last loaded.
>
>>
>>
>> Thanks,
>>
>>
>>
>> Adan
>>

Re: Backup Cache Group Selection

[Jeff Elsloo]

Steve: I don't think the patch is required, however, as Eric found,
without the patch there could be some gaps depending on the scenario.
That specific scenario revolved around the "next best cache group" not
having a DS assigned, or a healthy cache with the DS assigned. In that
case, despite the hits, you would still end up falling through to the
geolocation provider. The patch addresses that.

Eric: The rloc field is set via the Geolocation associated with the
CacheLocation, which ultimately comes from the edgeLocations section
of the CRConfig. When a CZF lookup is performed inside TR, a hit
returns a CacheLocation. When caches aren't available within that
CacheLocation, getClosestCacheLocation() is called, and that's why you
see the lat/long of the "next best cache group" instead of the actual
hit's lat/long.

If we want to have granularity in this situation, we might need to 1)
create a new RestultType, such as ResultType.CZ_NEXT (or something),
and/or 2) massage the log format such that we either have a the
original lat/long, and new lat/long in the rloc field, or create a new
field to save one or the other, such that we log both lat/longs.

Thoughts? Whatever we decide should go into TC-90 so we can apply the
proposed patch and improve the logging.
--
Thanks,
Jeff


On Fri, Jan 27, 2017 at 7:14 AM, Eric Friedrich (efriedri)
<efrie...@cisco.com> wrote:
> The rloc field usually indicates the Geolocation IP of the client (short for 
> request location)
>
> But here it looks like rloc is reflecting the location of the CG it 
> ultimately redirected to (response location?).
>
> I would have expected the rloc field to either
>1) be blank (because we never did a lookup from geoprovider)
> or
>2)  to contain the coordinates of the cache group the CZF hit on (in this 
> case us-ga-macon at 32.7261, -83.6547”)
>
> —Eric
>
>> On Jan 27, 2017, at 8:28 AM, Steve Malenfant <smalenf...@gmail.com> wrote:
>>
>> Jeff,
>>
>> CZF properly installed: yes
>> Network address or not: same behavior
>>
>> But you nailed the API one. There is no cache assigned to us-ga-macon,
>> which is exactly what I'm testing.
>>
>> I added cache groups for my testing in the lab which I assigned a few
>> caches to them :
>>
>> - us-ga-atlanta 34.0362 -84.3207
>> - us-ok-oklahomacity 35.4777 -97.5545
>> - us-va-nova 38.7922 -77.2136
>> - us-ca-sandiego 32.7205 -117.0838
>>
>> API :
>> {"locationByGeo":{"city":"Macon","countryCode":"US","latitude":"32.7288","postalCode":"31216","countryName":"United
>> States","longitude":"-83.6865"},"locationByFederation":"not
>> found","requestIp":"24.252.192.1","locationByCoverageZone":"not found"}
>>
>> Using the X-MM-Client-IP it returned the proper cache based on CZ, it
>> correctly sent the request to the cache in us-ga-atlanta :
>> 1485522786.423 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="34.03,-84.32" rdtl=- rerr="-" rgb="-" pssc=302 ttms=0.260 rurl="
>> http://cdn1cdedge0007.cox-col-jitp2.cdn1.coxlab.net/; rh="-"
>>
>> I then changed 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,-117.08" rdtl=- rerr="-" rgb="-" pssc=302 ttms=0.206 rurl="
>> http://cdn1cdedge0001.cox-col-jitp2.cdn1.coxlab.net/; rh="-
>>
>> I'm using 1.6.1 + patch discussed in this email. Not sure if those are
>> necessary but I'll need to try on unpatched version.
>>
>> Do we want to fix API to reflect CZF?
>>
>> Thanks for your help.
>>
>> Steve
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jan 26, 2017 at 4:47 PM, Jeff Elsloo <jeff.els...@gmail.com> wrote:
>>
>>> Dave just let me know that in this case you don't have any caches
>>> assigned in us-ga-macon. I'm not sure how the API behaves at that
>>> point – it likely won't follow the same "next best cache group" logic,
>>> as it was designed as a simple lookup tool.
>>>
>>> Can you try simulating a request through Traffic Router directly using
>>> the X-MM-Client-IP header, or fakeClientIpAddress query parameter
>>> u

Re: Backup Cache Group Selection

[Jeff Elsloo]

Are you 100% sure that the Traffic Router has loaded the updated CZF?
If so, what happens when you use an IP within the /20 instead of the
network address (.0)? I tried using a network address of a /22 on a
1.8 TR and it hit the CZF as expected. Ultimately what you're seeing
is a CZF miss, unrelated to the geo coordinates.

The underlying feature with the coordinates is to select the next best
cache group by proximity where healthy caches have a given delivery
service assigned. In order to test that, you would need to have a CZF
hit in a cache group which doesn't have that particular delivery
service assigned to any caches, or have all caches within that cache
group with that delivery service in an unhealthy state.

Thanks,
--
Thanks,
Jeff


On Wed, Jan 25, 2017 at 1:33 PM, Steve Malenfant <smalenf...@gmail.com> wrote:
> Jeff,
>
> I've tried this coverage zone file coordinate overwrite... I might be
> missing something.
>
> I defined the following :
>
> "us-ga-macon": {
>> "coordinates": {
>> "latitude": "32.7261",
>> "longitude": "-83.6547"
>> },
>> "network": [
>> "24.252.192.0/20",
>> "68.1.20.0/22",
>
>
> Then issued the following query :
>
>> curl http://traffic_router:/crs/stats/ip/24.252.192.0
>>
>> {"locationByGeo":{"city":"Macon","countryCode":"US","latitude":"32.7288","postalCode":"31216","countryName":"United
>> States","longitude":"-83.6865"},"locationByFederation":"not
>> found","requestIp":"24.252.192.0","locationByCoverageZone":"not found"}
>>
> I believe I'm expecting "locationByCoverageZone" to find something...
>
> I tried on 1.6.0 and 1.6.1 (patched with the pastebin above which I wasn't
> sure I was suppose to do).
>
> Would you mind giving me some light on this?
>
> Thanks,
>
> Steve
>
>
> On Mon, Jan 23, 2017 at 3:05 PM, Jeff Elsloo <jeff.els...@gmail.com> wrote:
>
>> Yes; the feature went into 1.5.x.
>> --
>> Thanks,
>> Jeff
>>
>>
>> On Thu, Jan 19, 2017 at 10:37 AM, Steve Malenfant <smalenf...@gmail.com>
>> wrote:
>> > I didn't know about this which is good information. Does that work on
>> > Traffic Router 1.6?
>> >
>> > On Mon, Jan 9, 2017 at 12:44 PM, Eric Friedrich (efriedri) <
>> > efrie...@cisco.com> wrote:
>> >
>> >> Jeff and I had a quick Slack convo, so I’ll add a followup summary here
>> in
>> >> case anyone else is interested.
>> >>
>> >> Cache Group location (lat/long) is configured in Traffic Ops today (and
>> is
>> >> used for computing distance from Maxmind Geolocation).
>> >>
>> >> You can also configure the location (lat/long) for a Cache Group in the
>> >> CoverageZone file (example below).
>> >>
>> >> When this location is configured (and Jeff’s suggested logic fix from
>> >> below is applied) and all caches in the mapped cache group are
>> unavailable,
>> >> TR will send a client request to the cache group that is closest to the
>> >> original mapped group.
>> >>
>> >> Example CZF w/ cache location
>> >> -
>> >> "coverageZones": {
>> >> “edge-cg-1": {
>> >>   "network6": [
>> >> ...
>> >>   ],
>> >>   "network": [
>> >> ...
>> >>   ],
>> >>   "coordinates": {
>> >> "longitude": “-75.3342",
>> >> "latitude": “42.555"
>> >>   }
>> >> },
>> >>
>> >>
>> >> —Eric
>> >>
>> >>
>> >> > On Jan 5, 2017, at 12:06 PM, Jeff Elsloo <jeff.els...@gmail.com>
>> wrote:
>> >> >
>> >> > If we applied the proposed change, given your scenario we should fall
>> >> > through to the return statement that calls getClosestCacheLocation().
>> >> > That method will order all cache groups based on their lat/long and
>> >> > the lat/long of the cache group we hit on in the CZF. Once the list is
>> >> > ordered, we iterate through the list u

Re: Backup Cache Group Selection

[Jeff Elsloo]

If we applied the proposed change, given your scenario we should fall
through to the return statement that calls getClosestCacheLocation().
That method will order all cache groups based on their lat/long and
the lat/long of the cache group we hit on in the CZF. Once the list is
ordered, we iterate through the list until we find a cache group that
has available caches for that DS.

BTW, the stuff on line 536 is likely to produce the exact same result
as the check that precedes it. networkNode.getLoc() will return the
string name of the cache group, so when we find the CacheLocation, it
will be the same as what we had just checked. We could probably get
away with removing that part of the method as it's redundant.
--
Thanks,
Jeff


On Wed, Jan 4, 2017 at 11:54 AM, Eric Friedrich (efriedri)
<efrie...@cisco.com> wrote:
> Where would TR look outside the assigned cache group to find 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>> wrote:
>>
>> 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?
>> Yes, exactly.
>>
>>
>> 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 long as you're
>> able to put your RFC 1918 ranges in the CZF.
>> Yes, we would want those ranges in the CZF. I can’t think of any other place 
>> they would go.
>>
>>
>> There's a small logic gap in the existing algorithm around cache
>> location selection and I think if we fix that (two line change), we
>> should be better off all around. I think the only time we'd ever want
>> to go to the geolocation provider is in the event of a miss on the
>> CZF, so as long as we have a hit there, we should find the cache group
>> closest to that hit location that has available caches. This would
>> automatically provide the "backup" cache group concept, and has the
>> added benefit of doing this selection dynamically based on the state
>> of the CDN.
>> Wow, thanks for picking up on this solution. Sounds like a strong 
>> possibility. I like that it can extend dynamically.
>>
>>
>>
>> See this to get an idea of what I mean: http://apaste.info/u3PQo
>> https://github.com/apache/incubator-trafficcontrol/blob/249bd7504eeb7cc43402126f3719017e2475ad33/traffic_router/core/src/main/java/com/comcast/cdn/traffic_control/traffic_router/core/router/TrafficRouter.java#L536
>> Does this line set cacheLocation to the closest cache group with active 
>> caches on that DS?
>>
>> What does networkNode.getLoc() actually return?
>>
>> —Eric
>>
>>
>>
>> Obviously we'd need to test this to ensure we don't break other 
>> functionality.
>> --
>> Thanks,
>> Jeff
>>
>>
>> On Tue, Jan 3, 2017 at 10:07 AM, Eric Friedrich (efriedri)
>> <efrie...@cisco.com<mailto:efrie...@cisco.com>> wrote:
>> If all caches in the primary cache group are unavailable, our goal is to 
>> provide a backup routing policy for RFC1918 clients.
>>
>> When client IP is an public Internet IP, the current backup policy is to 
>> assign the client to the geographically closest cache (Distance = MaxMind 
>> Geo Lat/Long - configured CG lat/long).
>>
>> When client IP is an RFC1918 IP, the client would not have a maxmind 
>> geo-loc, so would fall back to the DS geo-miss lat long. We’d prefer some 
>> more granular control over where these clients are routed to, rather than a 
>> per-DS setting.
>>
>>
>> So with an RFC1918 client, the lookup process would be (step 3 is only 
>> addition)
>> 1) Check CZF for a subnet match (and find a match for existing cache group). 
>> Assign client to CG
>> 2) Check CG for available (online and associated w/ DS) servers. In this 
>> particular case, assume CG has no servers available to route the client to
>> 3) Walk the CZF's list of backup CGs and perform the check from #2 for each 
>> CG. Use first server that is found
>> 4) Assuming no server is found in #3, perform geo-location and find closest 
>> cache group. Use a server from the closest CG if one is found
>> 4a) If geo-location returns null, use the DS’ default geo-miss location as 
>> the client location.
>>
>> —Eric
>>
>>
>> On Dec 26, 2016, at 10:01 AM, Jan van Door

Re: Backup Cache Group Selection

[Jeff Elsloo]

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 long as you're
able to put your RFC 1918 ranges in the CZF.

There's a small logic gap in the existing algorithm around cache
location selection and I think if we fix that (two line change), we
should be better off all around. I think the only time we'd ever want
to go to the geolocation provider is in the event of a miss on the
CZF, so as long as we have a hit there, we should find the cache group
closest to that hit location that has available caches. This would
automatically provide the "backup" cache group concept, and has the
added benefit of doing this selection dynamically based on the state
of the CDN.

See this to get an idea of what I mean: http://apaste.info/u3PQo

Obviously we'd need to test this to ensure we don't break other functionality.
--
Thanks,
Jeff


On Tue, Jan 3, 2017 at 10:07 AM, Eric Friedrich (efriedri)
 wrote:
> If all caches in the primary cache group are unavailable, our goal is to 
> provide a backup routing policy for RFC1918 clients.
>
> When client IP is an public Internet IP, the current backup policy is to 
> assign the client to the geographically closest cache (Distance = MaxMind Geo 
> Lat/Long - configured CG lat/long).
>
> When client IP is an RFC1918 IP, the client would not have a maxmind geo-loc, 
> so would fall back to the DS geo-miss lat long. We’d prefer some more 
> granular control over where these clients are routed to, rather than a per-DS 
> setting.
>
>
> So with an RFC1918 client, the lookup process would be (step 3 is only 
> addition)
> 1) Check CZF for a subnet match (and find a match for existing cache group). 
> Assign client to CG
> 2) Check CG for available (online and associated w/ DS) servers. In this 
> particular case, assume CG has no servers available to route the client to
> 3) Walk the CZF's list of backup CGs and perform the check from #2 for each 
> CG. Use first server that is found
> 4) Assuming no server is found in #3, perform geo-location and find closest 
> cache group. Use a server from the closest CG if one is found
> 4a) If geo-location returns null, use the DS’ default geo-miss location as 
> the client location.
>
> —Eric
>
>
>> On Dec 26, 2016, at 10:01 AM, Jan van Doorn  wrote:
>>
>> Hi Eric,
>>
>> How does the backup list relate to the RFC1918-is-not-in-geo problem?
>>
>> To get to a cachegroup you need to get a match in the coverage zone, I would 
>> think?
>>
>> Rgds,
>> JvD
>>
>>> On Dec 22, 2016, at 12:28, Eric Friedrich (efriedri)  
>>> wrote:
>>>
>>> The current behavior of cache group selection works as follows
>>> 1) Look for a subnet match in CZF
>>> 2) Use MaxMind/Neustar for GeoLocation based on client IP. Choose closest 
>>> cache group.
>>> 3) Use Delivery Service Geo-Miss Lat/Long. Choose closest cache group.
>>>
>>>
>>> For deployments where IP addressing is primarily private (say RFC-1918 
>>> addresses), client IP Geo Location (#2) is not useful.
>>>
>>>
>>> We are considering adding another field to the Coverage Zone File that 
>>> configures an ordered list of backup cache groups to try if the primary 
>>> cache group does not have any available caches.
>>>
>>> Example:
>>>
>>> "coverageZones": {
>>> "cache-group-01": {
>>>   “backupList”: [“cache-group-02”, “cache-group-03”],
>>>   "network6": [
>>> "1234:5678::\/64”,
>>> "1234:5679::\/64"],
>>>   "network": [
>>> "192.168.8.0\/24",
>>> "192.168.9.0\/24”]
>>> }
>>>
>>> This configuration could also be part of the per-cache group configuration, 
>>> but that would give less control over which clients preferred which cache 
>>> groups. For example, you may have cache groups in LA, Chicago and NY. If 
>>> the Chicago Cache group fails, you may want some of the Chicago clients to 
>>> go to LA and some to go to NY. If the backup CG configuration is per-cg, we 
>>> would not be able to control where clients are allocated.
>>>
>>> Looking for opinions and comments on the above proposal, this is still in 
>>> idea stage.
>>>
>>> Thanks All!
>>> Eric
>>>
>>>
>>
>

Re: Backup Cache Group Selection

[Jeff Elsloo]

Yes, it's expected behavior. What you're describing sounds like a
cachegroup in the CZF without any corresponding configuration in
Traffic Ops, or a cachegroup with configuration in Traffic Ops, but
with no available caches (DS assignments, health, etc).

Presuming we have configured geolocation coordinates within the CZF,
we know the lat/long of the cachegroup within the CZF that contains
the source address. We can then order our list of cachegroups by
lat/long, then select the "next best" cache group by distance and
availability. That will be the actual cachegroup to serve the request;
this prevents a miss on the CZF that would normally be routed to the
Geolocation service selected for the DS.

We do have a slight gap around logging, and maybe that's part of the
question. What we see in the log is the selected lat/long, not the
source lat/long of the hit, so we can't easily tell when we're in this
case by simply looking at logs. This could be an area of improvement,
however, we'll need to be careful to not conflate the logs with
unnecessary information. In most cases the hit is the selected
cachegroup, so we need to be careful to not just add "source" and
"actual" coordinates to the log because it'll be identical in most CZF
hit cases.

Thanks,
Thanks,
Jeff


On Wed, Mar 29, 2017 at 7:02 AM, John Shen (weifensh)
<weife...@cisco.com> wrote:
> Hi Jeff,
>
> I have just tried the getClosestCacheLocation() logic. It appears the CZF 
> matched lat/long does come from CZF, but the lat/long of the “closest” Cache 
> Groups is from the configuration by Ops. This means to calculate the distance 
> from the matched CG and “closest” CG, the source lat/long is from CZF, but 
> the dest lat/long is not from CZF but from CG 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 could be some gaps depending on the scenario.
> That specific scenario revolved around the "next best cache group" not
> having a DS assigned, or a healthy cache with the DS assigned. In that
> case, despite the hits, you would still end up falling through to the
> geolocation provider. The patch addresses that.
>
> Eric: The rloc field is set via the Geolocation associated with the
> CacheLocation, which ultimately comes from the edgeLocations section
> of the CRConfig. When a CZF lookup is performed inside TR, a hit
> returns a CacheLocation. When caches aren't available within that
> CacheLocation, getClosestCacheLocation() is called, and that's why you
> see the lat/long of the "next best cache group" instead of the actual
> hit's lat/long.
>
> If we want to have granularity in this situation, we might need to 1)
> create a new RestultType, such as ResultType.CZ_NEXT (or something),
> and/or 2) massage the log format such that we either have a the
> original lat/long, and new lat/long in the rloc field, or create a new
> field to save one or the other, such that we log both lat/longs.
>
> Thoughts? Whatever we decide should go into TC-90 so we can apply the
> proposed patch and improve the logging.
> --
> Thanks,
> Jeff
>
>
> On Fri, Jan 27, 2017 at 7:14 AM, Eric Friedrich (efriedri)
> <efrie...@cisco.com> wrote:
> > The rloc field usually indicates the Geolocation IP of the client 
> (short for request location)
> >
> > But here it looks like rloc is reflecting the location of the CG it 
> ultimately redirected to (response location?).
> >
> > I would have expected the rloc field to either
> >1) be blank (because we never did a lookup from geoprovider)
> > or
> >2)  to contain the coordinates of the cache group the CZF hit on (in 
> this case us-ga-macon at 32.7261, -83.6547”)
> >
> > —Eric
> >
> >> On Jan 27, 2017, at 8:28 AM, Steve Malenfant <smalenf...@gmail.com> 
> wrote:
> >>
> >> Jeff,
> >>
> >> CZF properly installed: yes
> >> Network address or not: same behavior
> >>
> >> But you nailed the API one. There is no cache assigned to us-ga-macon,
> >> which is exactly what I'm testing.
> >>
> >> I added cache groups for my testing in the lab which I assigned a few
> >> caches to them :
> >>
> >> - us-ga-atlanta 34.0362 -84.3207
> >> - us-ok-oklahomacity 35.4777 -97.5545
> >> - us-va-nova 38.79

Re: Backup Cache Group Selection

[Jeff Elsloo]

It could now be considered the "average" of the location of the
clients within that section of the CZF, however, it should be noted
that the addition of the geo coordinates to the CZF is relatively new.
Previously we never had the ability to specify lat/long on those
cachegroups, and we solely relied on those specified in edgeLocations,
meaning that the matches had to be 1:1. Adding the coordinates allowed
us to cover edge cases and miss scenarios and stick to the CZF
whenever possible. Previously when we had no coordinates, and we had a
hit in the CZF but not corresponding hit within the edgeLocations
(health, assignments, etc), we would fall back to the Geolocation
provider.
--
Thanks,
Jeff


On Thu, Mar 30, 2017 at 5:29 AM, John Shen (weifensh)
<weife...@cisco.com> wrote:
> Thanks Jeff and Oren for the discussion. I agree now that lat/long from CZF 
> is the “average” location of clients, and lat/long from Ops is the location 
> of a certain Cache Group. So it appears to be reasonable to use them as 
> source and dest to calculate the distance.
>
> Thanks,
> John
>
>
> On 30/03/2017, 6:55 PM, "Oren Shemesh" <or...@qwilt.com> wrote:
>
> Jeff, having read this conversation more than once, I believe there is a
> misunderstanding regarding the ability to provide coordinates for cache
> groups both in the CZF and in the TO DB.
>
> Here is what I believe is a description which may help understanding the
> current behaviour:
>
> The coordinates specified in the CZF for a cache group are not supposed to
> be the exactly same as the coordinates in the TO DB for the same cache
> group.
> This is because they do not represent the location of the caches of the
> group.
> They represent the (average) location of clients found in the subnets
> specified for this cache group.
>
> This, I believe, explains both the behaviour of the code (Why the
> coordinates from the CZF are used for 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:
>
> > The cachegroup settings in the Traffic Ops GUI end up in the
> > `edgeLocations` section of the CRConfig. This is the source of truth
> > for where caches are deployed, logically or physically. We do not
> > provide a means to generate a CZF in Traffic Ops, so it's up to the
> > end user to craft one to match what is in Traffic Ops.
> >
> > There are several cases that need to be accounted for where a hit in
> > the CZF does match what's in `edgeLocations`, but cannot be served
> > there due to cache health, delivery service health, or delivery
> > service assignments. The other edge case is a hit where no
> > `edgeLocation` exists, which again, must be accounted for. Presumably
> > we have higher fidelity data in our CZF than we would in our
> > Geolocation provider and we should use it whenever possible.
> >
> > Think about this: what if you use the same CZF for two configured
> > CDNs, but one of the two CDNs only has caches deployed to 50% of the
> > cache groups defined in the CZF. Would we want to use the Geolocation
> > provider in the event that our source address matches a cachegroup
> > that does not have any assigned caches? We would ideally have as much
> > granularity as possible in the CZF, then use that to inform the
> > decision about which cachegroup should service the request instead of
> > falling back to a lower fidelity datasource. This is especially true
> > in the case of RFC 1918 addresses that might appear in one's CZF.
> >
> > Thanks,
> > Jeff
> >
> >
> > On Wed, Mar 29, 2017 at 9:12 AM, John Shen (weifensh)
> > <weife...@cisco.com> wrote:
> > > Hi Jeff,
> > >
> > > Thank you for the detail. I am wondering why there are two sets of
> > lat/lang,
> > > i.e. one in CZF, the other is in Ops GUI Cache Group setting. To
> > calculate
> > > the closest CG when matched CG in CZF is not available, the source
> > lat/long
> > > is from mathced CZF, and the dest lat/long is from Ops setting, which
> > doesnt
> > > seem to be consistent. Is there any reason why TR has this behavior?
> > >
> > > Since there are two sets of lat/long in TR, can we just use the 
> lat/long
> > all

Re: Public CI Builds for Traffic Control

[Jeff Elsloo]

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 out in the open, we still have the `build.sh`
option. I was able to use the build script to successfully build all
components from master yesterday.
--
Thanks,
Jeff


On Tue, Mar 14, 2017 at 8:27 PM, Chris Lemmons  wrote:
> Yeah, there're unfortunately good reasons not to have any accounts with
> write permission in the GitHub repo. It can cause all sorts of problems if
> anything were actually pushed. It also allows lots of other things like
> editing other people's comments. GitHub should really separate that out for
> the purpose of bots with minimum required access anyway. But yeah, without
> write, it's a no-go. Comments are a very reasonable alternative, though.
>
> It's definitely worth a few minutes to get things set up on the ASF Jenkins
> if those ubuntu slaves have the requirements. As it stands, the only
> requirements for a build are:
>
>- git
>- bash
>- docker
>- docker-compose
>   - which requires python
>
> I believe the first three are satisfied by the build hosts. I don't know
> that docker-compose is available. It's 100% worth finding out, though.
>
> If it's not, we can do one of:
>
>- Run docker-compose inside a docker instance with the docker port
>forwarded into the container to allow it to manage sibling containers.
>- Re-create the subset of docker-compose behaviour that we actually use
>in a build script.
>- Give up.
>
> I mention the first option only because People on the Internet seem to keep
> suggesting it. I believe madness that way lies. I dislike giving up, so for
> lack of a better option, perhaps we might need to ditch docker-compose.
> I've got a PR open that wraps docker compose in a unified script. It
> wouldn't be entirely unreasonable to shift a bit more logic into it.
>
> Another possibility is to see if the infra folks would mind adding python
> and docker-compose. I'm not sure adding python to the mix on those boxen is
> a good idea, though, even if they're willing.
>
> On Tue, Mar 14, 2017 at 6:03 PM Leif Hedstrom  wrote:
>
>
>> On Mar 14, 2017, at 6:15 PM, Chris Lemmons  wrote:
>>
>> Honestly, the key is hosting. If we have a host for CI that runs the basic
>> build steps, we can configure any solution to build all the changes on
>> branches of a collection of repos on Github. Pretty much all the
> reasonable
>> options have a status update script on GitHub, which integrates it quite
>> nicely. (And therein might lie the rub. I think GitHub ties status updates
>> to "push permission", which may be false for everyone on the main repo,
>> since it's just a mirror.) But direct integration or no, we'd be able to
> go
>> look at the results and even download the binary, install it on a test
>> system and watch it go.
>
>
> So, we do not have the Jenkins master have “write permission” into the
> Github repo. I asked Infra before, and they said no, but I’ll try again.
>
> However, things can still work reasonably well, since any registered Github
> accounts is able to comment on a PR / issue. So, no, we can’t set labels
> etc. automatically from the Jenkins master, but we get pretty good feedback
> on what happens with the builds. See e.g.
>
> https://github.com/apache/trafficserver/pull/1581 <
> https://github.com/apache/trafficserver/pull/1581>
>
>
> Cheers,
>
> — leif
>
>>
>> Now, that doesn't get us automatic builds from first-time or probably even
>> very occasional contributors. But stick builds on the most frequent
>> contributors' clones and we get 95% of the benefit without solving any of
>> the actually hard problems.
>>
>> We'd need a host, though.
>>
>> On Tue, Mar 14, 2017 at 5:06 PM Leif Hedstrom  wrote:
>>
>>>
 On Mar 13, 2017, at 8:44 AM, Chris Lemmons  wrote:

 To me, the key features of CI are that a) it builds each branch
 automatically, b) notifies affected parties when all is not well, and c)
 manages the artefacts in a reasonable way. Additionally, we're a lot
> more
 useful when we're writing neat software and not spending out time
>>> managing
 CI, so it should be as automatic as reasonable. We're using github for
>>> PRs,
 so if it's at all possible to get automatic PR tagging with build
 information, that is greatly desirable. Knowing that the PR breaks the
 build prior to merging it can save quite a bit of time. :)
>>>
>>>
>>> My $0.25: My experience is that making as much CI build / tests on pull
>>> requests, *before* they are landed, gives the most bang for the buck. But
>>> that might not work well for you, since you can’t use Github right?
>>>
>>> — leif
>>>

Re: Traffic Router Cors

[Jeff Elsloo]

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

[Jeff Elsloo]

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 header with the preferred endpoint URL
3) JSON response body containing multiple URLs, the first URL is the
same as the Location header

We've built this feature on top of the steering delivery feature, but
extended it to allow us to return a list of URLs based on the
subordinate delivery services instead of a single endpoint based on
one of the subordinate delivery services. We use the same code and
consistent hashing, but we now include, in order, the "best" endpoint
across all subordinate delivery services.

The following is an example request if we have a multi-location
steering delivery service, foo, and two subordinates: foo-a, foo-b,
noting the two different delivery services in the JSON body:

> GET /a HTTP/1.1
> Host: tr.foo.cdn.example.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
< Server: Apache-Coyote/1.1
< Location: http://cache-01.foo-a.cdn.example.com/a
< Content-Type: application/json
< Content-Length: 149
< Date: Wed, 01 Mar 2017 18:00:11 GMT
<
{ [149 bytes data]
* Connection #0 to host localhost left intact
{
   "locations" : [
  "http://cache-01.foo-a.cdn.example.com/a;,
  "http://cache-01.foo-b.cdn.example.com/a;
   ]
}

Another important implementation detail is that not all HTTP client
libraries are able to parse a JSON body when a 302 response and
Location header are present. Because of this, we are also allowing a
query parameter, currently "redirect=false", which will cause a 200
response with no Location header. This is similar to the "format=json"
query parameter precedent that we currently allow for
non-multi-location responses.

In Traffic Ops, we will introduce a new type called "CLIENT_STEERING"
and an additional boolean value in the steering.json API endpoint
called clientSteering. Traffic Router will consume this, see the value
and serve a multi-location response if set to true.

Phil's draft can be found here: https://github.com/PSUdaemon/multi-location

Questions/comments welcome.
--
Thanks,
Jeff

Re: Adding support for per-DeliveryService routing names

[Jeff Elsloo]

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 addition to the HTTP routing name case. This also
applies to the pre-upgrade steps. I think this should be acceptable as
long as we make sure to call it out in the release notes.

Along the lines of what Jeremy suggested, I think we can make the new
delivery service routing name column not-null and not break the
existing API, so long as we have suitable defaults. This should only
apply to the create case, as it can remain optional once set for any
future update. If we can leave the http.routing.name and
dns.routing.name profile parameters in place, we will have a
configurable default, and can fall back to something that's hardcoded
(tr, edge) if the parameters are missing.
--
Thanks,
Jeff


On Mon, Aug 14, 2017 at 5:25 PM, Peters, Rawlin
 wrote:
> Jeremy’s suggestion could work, but the param would probably be created in a 
> TR_PROFILE per-CDN. However, that still wouldn’t fix the visibility problem. 
> If a CDN isn’t using the default “tr” HTTP routing name, operators would 
> still need to know that there is a new profile parameter that needs updating 
> post-upgrade but before a snap/queue. So either way there needs to be 
> sufficient upgrade notes, but personally I still prefer keeping the 
> routing_name column non-null.
>
> That said, this is my current proposal for the DB migration which also gets 
> us past the upgrade issue:
> 1. Add a routing_name column to the DeliveryService table.
> 2. Update the routing_name for DNS Delivery Services to “edge”.
> 3. Update the routing_name of non-DNS Delivery Services to the value of a 
> temporary upgrade parameter associated with the Delivery Service’s CDN (if 
> the upgrade parameter doesn’t exist, the routing_names will remain null).
> 4. Update the remaining null routing_names to “tr”.
> 5. Make the routing_name column non-null and add a non-empty constraint.
>
> So these would be an operator’s pre-upgrade steps:
> 1. Verify if a custom http.routing.name has been configured for Traffic 
> Routers in their CDNs.
> 2. If custom http.routing.name, do the following. Otherwise, no pre-upgrade 
> steps needed (for per-DS routing names at least):
> a. create a parameter named “upgrade_http_routing_name” with the value of 
> the target CDN’s custom http.routing.name
> b. associate this parameter to the TR_PROFILE belonging to the target CDN
> c. repeat steps 2a and 2b for each CDN using a custom http.routing.name
>
> This would keep everything working the same post-upgrade as it did 
> pre-upgrade, and from that point on you’d be able to change a Delivery 
> Service’s routing name to any arbitrary hostname (without periods).
>
> --Rawlin
>
> On 8/14/17, 4:22 PM, "Dave Neuman"  wrote:
>
> I don't think that solves the issue Rawlin was describing.  The issue that
> Rawlin was describing is that someone has already defined a different
> routing name in traffic_router/http.properties which is no longer going to
> be used after the upgrade.  The upgrade needs to somehow know about this
> other routing name and use that when it creates the database column and
> populates it with the pre-defined defaults (edge, tr).
>
> Also, creating a global param doesn't help those with more than 1 CDN.
>
> On Mon, Aug 14, 2017 at 4:09 PM, Jeremy Mitchell 
> wrote:
>
> > Adding a temp parameter would work but I worry that someone won't read 
> the
> > upgrade documentation and forget to create this temporary parameter 
> before
> > running the upgrade.
> >
> > Here's another option.
> >
> > Create 2 global TO parameters (http.routing.name and dns.routing.name
> > ) that default to tr and edge respectively 
> and
> > make the ds.routing_name an optional field.
> >
> > in seeds.sql
> >
> > insert into parameter (name, config_file, value) values ('
> > http.routing.name',
> > 'global', 'tr') ON CONFLICT (name, config_file, value) DO NOTHING;
> > insert into parameter (name, config_file, value) values 
> ('dns.routing.name
> > ',
> > 'global', 'edge') ON CONFLICT (name, config_file, value) DO NOTHING;
> >
> > in code (warning. ugly pseudo code to follow):
> >
> > function getRoutingName(ds) {
> > return ds.routing_name if not null
> > if (ds.type = HTTP) {
> > return parameter.http.routing.name
> > } else
> > return parameter.dns.routing.name
> > }
> > }
> >
> > Just my 2 cents.
> >
> > On Mon, Aug 14, 2017 at 10:55 AM, Dave Neuman  wrote:
> >
> > > Good info Rawlin.
> > > My vote would 

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

[Jeff Elsloo]

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 affected

Description:
The Traffic Router component of the incubating Apache Traffic Control
project is vulnerable to a Slowloris style Denial of Service attack.
TCP connections made on the configured DNS port will remain in the
ESTABLISHED state until the client explicitly closes the connection or
Traffic Router is restarted. If connections remain in the ESTABLISHED
state indefinitely and accumulate in number to match the size of the
thread pool dedicated to processing DNS requests, the thread pool
becomes exhausted. Once the thread pool is exhausted, Traffic Router
is unable to service any DNS request, regardless of transport
protocol.

Mitigation:
1.8.x users should upgrade to 1.8.1
2.0.x users should upgrade to 2.0.0
Pre 1.8.x users can apply this patch:
https://github.com/apache/incubator-trafficcontrol/commit/738c10fa1b5861e4cc3944dc7c3065d16f4a708c

References:
http://trafficcontrol.apache.org/security/index.html
--
Thanks,
Jeff

Re: Obsolete Traffic Ops API endpoint removal

[Jeff Elsloo]

+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 incomplete prototype that has the potential
to mislead and confuse instead of help, and our components certainly
aren't moving to it.

Additionally, when developing goTM, we quickly discovered that our
idea to move away from the snapshots with this route and
monitoring.json was not realistic with Traffic Ops today. We should
re-evaluate the CRConfig when we decide to tackle the more targeted
config changes and/or the config state machine, because those changes
will involve consumers of the CRConfig in addition to the caching
tier(s).
--
Thanks,
Jeff


On Thu, Jul 6, 2017 at 12:38 PM, David Neuman  wrote:
> Hey Rawlin,
> I took a look through our splunk logs and it looks like we don't have
> anything at Comcast that has hit that endpoint in the last 90 days.
> For this reason, I am +1 on removing.
>
> Thanks,
> Dave
>
> On Thu, Jul 6, 2017 at 11:27 AM, Robert Butts 
> wrote:
>
>> This isn't obsolete, so much as a prototype. It was intended to be "better"
>> than the CRConfig and replace it for TR. Much the same way
>> `configs/monitoring.json` is the "next generation" endpoint for Traffic
>> Monitor (and which is now used in the Golang TM).
>>
>> That said, as you say, it's incomplete and not currently in use by Traffic
>> Control, and probably not useful. I don't have a strong opinion, if you
>> want to push for deprecating and removing it. I do have a strong opinion,
>> that it should be marked "deprecated" in the next release, and removed in
>> the release after, not immediately removed. That should be the normal
>> procedure, we should give anyone using Traffic Control a chance to migrate
>> before removing things.
>>
>>
>> On Thu, Jul 6, 2017 at 11:14 AM, Peters, Rawlin > >
>> wrote:
>>
>> > Hey all,
>> >
>> > I believe I’ve found an obsolete/broken API endpoint [1] that might be a
>> > good candidate for removal. Here is an example request:
>> >
>> > GET /api/1.2/cdns/mycdn/configs/routing
>> >
>> > This will return a json object that looks like the following:
>> >
>> > {
>> > “response”: {
>> > “trafficServers”: […],
>> > “stats”: {…},
>> > “cacheGroups”: […],
>> > “config”: {…},
>> > “trafficMonitors”: […],
>> > “trafficRouters”: […]
>> > }
>> > }
>> >
>> > As you might notice, this looks very similar to CRConfig.json except that
>> > most of the keys are named differently (e.g. “trafficRouters” vs.
>> > “contentRouters”). There is a lot of overlapping information between this
>> > and CRConfig which makes me believe that perhaps this API was a precursor
>> > to CRConfig that is now obsolete. Further evidence that it’s out-of-date
>> > includes (among other things) missing “httpsPort” fields in the objects
>> and
>> > empty “deliveryServices” arrays for every “trafficServer” object (the
>> > arrays shouldn’t be empty if there are delivery services assigned). Also,
>> > it seems to be targeted for Traffic Router usage, but Traffic Routers
>> > currently pull their CRConfig from Traffic Monitors.
>> >
>> > The following API endpoints [2][3] seem to provide more up-to-date
>> > information via CRConfig and should already replace the outdated endpoint
>> > above:
>> >
>> > GET /api/1.2/cdns/mycdn/snapshot
>> > GET /genfiles/view/bycdnname/mycdn/CRConfig.json
>> >
>> > I propose that we remove this API endpoint [1] unless someone can verify
>> > that it’s still in use somewhere (with a good reason to not use a
>> CRConfig
>> > endpoint instead). I will wait a few days for responses before starting
>> on
>> > a Pull Request to remove it.
>> >
>> > Thanks,
>> > Rawlin Peters
>> >
>> > [1] https://github.com/apache/incubator-trafficcontrol/blob/
>> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L469
>> > [2] https://github.com/apache/incubator-trafficcontrol/blob/
>> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L439
>> > [3] https://github.com/apache/incubator-trafficcontrol/blob/
>> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L331
>> >
>> >
>>

Re: traffic_router tomcat init script (shutdown) problems

[Jeff Elsloo]

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, but Traffic Router does not service
any long running sessions, so getting it shut down quickly is actually
desired.

We can use this new init script and make changes as necessary in the
future, but this should be an improvement. Hopefully we won't have to
`kill -9 ` anymore.
--
Thanks,
Jeff


On Tue, Jul 11, 2017 at 3:37 PM, Jason Tucker  wrote:
> FYI - opened ticket and PR for this issue:
>
> The tomcat init script has a few problems:
>
> 1. "Clean" shutdowns frequently timeout, and the scripts give up, leaving
> tomcat running
>
> 2. Normal tomcat shutdown actually involves spinning up a second jvm
> instance. Right now, we start this second instance with the same
> CATALINA_OPTS as traffic_router, which can be problematic on
> memory-constrained hosts.
>
> https://issues.apache.org/jira/browse/TC-416
> https://github.com/apache/incubator-trafficcontrol/pull/724
>
> Thanks,
>
> _Jason

Promote Golang Traffic Monitor to Default

[Jeff Elsloo]

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 version string used for the golang version's RPM.

Rob and I both think we (Comcast) have enough experience running the
golang version that we have identified and corrected any major issues
and that it is stable enough to be the preferred Traffic Monitor hence
forth.

Therefore, I propose that within the project's directory structure, we:
  1) rename traffic_monitor to traffic_monitor_legacy
  2) rename traffic_monitor_golang to traffic_monitor

..then work with the person that submitted the PR to take the same
approach, except change the Java version's RPM name to contain
`_legacy`.

I realize that this is a fairly significant change, the type that we
typically reserve for major releases. The next major release, 3.0.0,
is likely to be some time out in the future, and I don't know that we
need to wait for it in order to make this change.

How does the group feel about the above proposal, and executing on it
prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
actually prepare the 3.0.0 release, we can remove the Java version
from the codebase entirely. Obviously this could impact anyone that
has automated CI systems building components, in addition to the
Apache CI we use ourselves.

Thoughts?

[1] https://github.com/apache/incubator-trafficcontrol/pull/731
--
Thanks,
Jeff

Re: Promote Golang Traffic Monitor to Default

[Jeff Elsloo]

For the most part, it's a drop in replacement for the Java version,
and based on our own experience it seems to work exactly as the Java
version would, including co-existence. There is a TO API dependency
for monitoring.json that the Java version does not have, and I'm not
sure what the history is with that endpoint and how far back we could
remain compatible. Traffic Router does not care what version of
Traffic Monitor it talks to, as the format of cr-states.json has not
changed. Same goes for TM and ATS. I believe we had co-existence
running in production going back to the 1.8.x releases.

Keep in mind that the intent is to drive users toward using the Golang
component by default starting with the 2.1.0 (or maybe 2.2.0?) release
while still allowing one to build, run, or contribute to the Java
version until our next major release (3.0.0). The intent is not to
give people a drop in replacement that works with prior versions; we
have not tested that thoroughly across all versions, and while it
might work, we should think of the Golang Traffic Monitor as a 2.0.x
and onward component. I think that statement holds for most of our
components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
Traffic Ops system. 1.7 is ancient, and have we ever really done
backward compatibility testing with versions?

To this end, if we do decide to make the Golang version the default in
the future, at a minimum we will need to provide release notes that
explain how to convert the Java configuration to the Golang version's
config. Ideally we would provide a simple script to convert the
configuration for our users, potentially running it as a postinstall
scriptlet in the RPM if the Java version is already installed.
Theoretically we could `yum upgrade traffic_monitor` and seamlessly
move from Java to Golang.
--
Thanks,
Jeff


On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
<efrie...@cisco.com> wrote:
> I think I remember Rob making this point in Miami, but all of TMs APIs (REST, 
> CRConfig, Health.json, etc…) are identical between the Java and Golang 
> version, right?
>
> What about compatibility with earlier versions of TC?
>
> For example:
> - Can a TC1.7 traffic ops configure a Golang TM?
> - Does the Golang TM have any dependencies on a certain version of 
> TrafficServer or astats?
> - Whats the minimum required 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:
>>
>> 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 version string used for the golang version's RPM.
>>
>> Rob and I both think we (Comcast) have enough experience running the
>> golang version that we have identified and corrected any major issues
>> and that it is stable enough to be the preferred Traffic Monitor hence
>> forth.
>>
>> Therefore, I propose that within the project's directory structure, we:
>>  1) rename traffic_monitor to traffic_monitor_legacy
>>  2) rename traffic_monitor_golang to traffic_monitor
>>
>> ..then work with the person that submitted the PR to take the same
>> approach, except change the Java version's RPM name to contain
>> `_legacy`.
>>
>> I realize that this is a fairly significant change, the type that we
>> typically reserve for major releases. The next major release, 3.0.0,
>> is likely to be some time out in the future, and I don't know that we
>> need to wait for it in order to make this change.
>>
>> How does the group feel about the above proposal, and executing on it
>> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
>> actually prepare the 3.0.0 release, we can remove the Java version
>> from the codebase entirely. Obviously this could impact anyone that
>> has automated CI systems building components, in addition to the
>> Apache CI we use ourselves.
>>
>> Thoughts?
>>
>> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
>> --
>> Thanks,
>> Jeff
>

Re: Traffic Ops Golang Migration Proposal

[Jeff Elsloo]

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 might not be installed. This means that the traffic_ops side
would have to check to see whether traffic_ops_golang is installed
outside of the normal RPM dependencies, adding more platform specific
code to postinstall. I don't see a generic way to implement the
"check" for the golang package within postinstall that will work. We
would have to check for a path that is not likely to exist for most
users, or check for a package. Both approaches require platform
specific code and assumptions.

Because the traffic_ops_golang package will depend on traffic_ops, not
the other way around, it makes more sense to place the configuration
piece in the golang package. When the golang package is installed, we
can "take over" the port in the listen directive of cdn.conf, because
we know for a fact that it is on disk because of the RPM dependency on
traffic_ops. We also know that cdn.conf will be left alone if/when
traffic_ops is upgraded due to being marked as a config file. If the
user has installed either component outside of the normal RPM process,
they will have to figure out how to run the golang package separately,
as one would expect.

We can do the configuration during the postinstall step of the
traffic_ops_golang RPM. It's advantageous to manage that piece within
the RPM, because if, for example, one wanted to remove the golang
portion, we could have a postuninstall step that reverts changes made
to cdn.conf (put the port we took over back into cdn.conf). We could
seamlessly add and remove the traffic_ops_golang component without
disturbing anything in traffic_ops, and without having to run some
script manually. The platform specific things that would need to be
done in postinstall should be done in the RPM, because then we know
for sure which platform we're on, and assumptions about packages and
paths will be accurate.

Ideally we should be moving away from any manual run of any script
after an installation or upgrade, including postinstall, if that work
can be done within the RPM.
--
Thanks,
Jeff


On Wed, Jul 19, 2017 at 9:08 AM, Robert Butts  wrote:
> It sounds like the only -1 is having a unified Service and RPM.
>
> How about the following compromise: a separate RPM and Service for the New
> TO, and the New TO RPM is a dependency of Old TO, and likewise the Service
> is a dependency of `traffic_ops`. This way, upgrades will still require
> building the New TO RPM and adding it to Yum, but `yum upgrade` will
> automatically install it without additional ops work, and `service
> traffic_ops start` will also start the New TO. Bearing in mind this
> double-service awkwardness will go away when all endpoints are migrated.
>
> Also, @alficles suggested configuring the New TO Config in Postinstall
> (which must be run after upgrading anyway). Because the New is a dependency
> of the Old, we're guaranteed `/opt/traffic_ops_golang` exists in
> Postinstall, and can populate its config.
>
> Also, I realized the New TO needs moved from
> `/traffic_ops/traffic_ops_golang` to `/traffic_ops_golang`, because
> `build_all.sh` requires projects be in the root directory.
>
> Also, I will add tests, docs, and configurable logging before the PR is
> merged. (Just wanted to wait until we had consensus before putting more work
> into it.)
>
> How does that sound?
>
>
> On Thu, Jul 13, 2017 at 1:00 PM, Robert Butts 
> wrote:
>>
>> @dewrich It's not that putting both services in the same Service and RPM
>> is a good long-term solution; it's that it's easier to configure and deploy.
>> A separate RPM and service is another step to install, and another step to
>> start the service. It's not that it's good, it's that it's the lesser of two
>> evils. My fear is, the more complex we make this, the less chance of getting
>> it done at all.
>>
>> @efriedri
>> 1. Same answer: long-term, I absolutely agree proxies should be separate.
>> But this is the simplest way to deploy an incremental migration.
>> 2. Yes, the Perl GUI can transparently request what it needs. That's a
>> goal of this: transparent new endpoints, that existing services don't know
>> or care that they come from a different backend.
>>
>> Also bear in mind, this "proxy" only exists until Perl TO goes away.
>> Having it in the same Service and RPM as old TO, and having the proxy be the
>> same binary as the new endpoints, makes it easier to completely remove the
>> Proxy and Perl, once every endpoint is rewritten. If we make the Service and
>> RPM separate, you have to change configs and uninstall the separate Service
>> and RPM of the Perl TO. If the Proxy is a separate binary, you have to
>> uninstall that, and then change 

Re: Promote Golang Traffic Monitor to Default

[Jeff Elsloo]

It sounds like we do not have any -1s on this, so I'm going to assume
we're good to make this change. I have some other things to focus on
at the moment, but will try to get this done as time permits. I'll
send another email out with details when I go to make the change, and
will allow some time before pushing anything in case someone has
concerns.
--
Thanks,
Jeff


On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <neu...@apache.org> wrote:
> +1 on the rename
>
> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <j...@knutsel.com> wrote:
>
>> +1
>>
>> 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
>> >
>> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <els...@apache.org> wrote:
>> >
>> > > For the most part, it's a drop in replacement for the Java version,
>> > > and based on our own experience it seems to work exactly as the Java
>> > > version would, including co-existence. There is a TO API dependency
>> > > for monitoring.json that the Java version does not have, and I'm not
>> > > sure what the history is with that endpoint and how far back we could
>> > > remain compatible. Traffic Router does not care what version of
>> > > Traffic Monitor it talks to, as the format of cr-states.json has not
>> > > changed. Same goes for TM and ATS. I believe we had co-existence
>> > > running in production going back to the 1.8.x releases.
>> > >
>> > > Keep in mind that the intent is to drive users toward using the Golang
>> > > component by default starting with the 2.1.0 (or maybe 2.2.0?) release
>> > > while still allowing one to build, run, or contribute to the Java
>> > > version until our next major release (3.0.0). The intent is not to
>> > > give people a drop in replacement that works with prior versions; we
>> > > have not tested that thoroughly across all versions, and while it
>> > > might work, we should think of the Golang Traffic Monitor as a 2.0.x
>> > > and onward component. I think that statement holds for most of our
>> > > components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
>> > > Traffic Ops system. 1.7 is ancient, and have we ever really done
>> > > backward compatibility testing with versions?
>> > >
>> > > To this end, if we do decide to make the Golang version the default in
>> > > the future, at a minimum we will need to provide release notes that
>> > > explain how to convert the Java configuration to the Golang version's
>> > > config. Ideally we would provide a simple script to convert the
>> > > configuration for our users, potentially running it as a postinstall
>> > > scriptlet in the RPM if the Java version is already installed.
>> > > Theoretically we could `yum upgrade traffic_monitor` and seamlessly
>> > > move from Java to Golang.
>> > > --
>> > > Thanks,
>> > > Jeff
>> > >
>> > >
>> > > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
>> > > <efrie...@cisco.com> wrote:
>> > > > I think I remember Rob making this point in Miami, but all of TMs
>> APIs
>> > > (REST, CRConfig, Health.json, etc…) are identical between the Java and
>> > > Golang version, right?
>> > > >
>> > > > What about compatibility with earlier versions of TC?
>> > > >
>> > > > For example:
>> > > > - Can a TC1.7 traffic ops configure a Golang TM?
>> > > > - Does the Golang TM have any dependencies on a certain version of
>> > > TrafficServer or astats?
>> > > > - Whats the minimum required 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:
>> > > >>
>> > > >> Hi all,
>> > > >>
>> > > >> We currently have two versions of Traffic Monitor: Java and golang.
>> > > >> When we build 

Re: Traffic Ops Golang Migration Proposal

[Jeff Elsloo]

I see. If that's the case, it's a hard requirement to run the golang
portion from whenever this is introduced onward. As long as we have
discipline around removing migrated routes, that should work okay and
would solve the "two watches" issue Mark mentioned when we discussed
this in person: A man with two watches (old API route, golang route)
does not know what time it is.

I don't think that it makes a lot of sense to have a separate RPM
since the dependency goes the other direction, and users are required
to run the golang component no matter what. We might as well just
build that into the existing RPM build process for traffic_ops.

Do we really need to ask the user for the port to move mojo to?
Obviously we can ask them to provide a port, but we could also just
pick a random, unused high port, and have mojo listen only on the
loopback interface. Maybe that's too "magical"?

Does the golang app run as trafops:trafops and drop privileges after
opening :443?
--
Thanks,
Jeff


On Wed, Jul 19, 2017 at 11:58 AM, Robert Butts <robert.o.bu...@gmail.com> wrote:
>> This means that the traffic_ops side would have to check to see whether
>> traffic_ops_golang
>
>> Because the traffic_ops_golang package will depend on traffic_ops, not the
>> other way around
>
> I was suggesting the other way around - traffic_ops will depend on
> traffic_ops_golang. Which means upgrading traffic_ops automatically installs
> traffic_ops_golang, and we don't need to do the check. It'd mean you
> couldn't remove `traffic_ops_golang`, but the plan is to remove old
> endpoints from old TO anyway. Which is another reason making
> traffic_ops_golang a dependency of traffic_ops makes sense: it really is,
> traffic_ops really 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> wrote:
>>
>> 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 might not be installed. This means that the traffic_ops side
>> would have to check to see whether traffic_ops_golang is installed
>> outside of the normal RPM dependencies, adding more platform specific
>> code to postinstall. I don't see a generic way to implement the
>> "check" for the golang package within postinstall that will work. We
>> would have to check for a path that is not likely to exist for most
>> users, or check for a package. Both approaches require platform
>> specific code and assumptions.
>>
>> Because the traffic_ops_golang package will depend on traffic_ops, not
>> the other way around, it makes more sense to place the configuration
>> piece in the golang package. When the golang package is installed, we
>> can "take over" the port in the listen directive of cdn.conf, because
>> we know for a fact that it is on disk because of the RPM dependency on
>> traffic_ops. We also know that cdn.conf will be left alone if/when
>> traffic_ops is upgraded due to being marked as a config file. If the
>> user has installed either component outside of the normal RPM process,
>> they will have to figure out how to run the golang package separately,
>> as one would expect.
>>
>> We can do the configuration during the postinstall step of the
>> traffic_ops_golang RPM. It's advantageous to manage that piece within
>> the RPM, because if, for example, one wanted to remove the golang
>> portion, we could have a postuninstall step that reverts changes made
>> to cdn.conf (put the port we took over back into cdn.conf). We could
>> seamlessly add and remove the traffic_ops_golang component without
>> disturbing anything in traffic_ops, and without having to run some
>> script manually. The platform specific things that would need to be
>> done in postinstall should be done in the RPM, because then we know
>> for sure which platform we're on, and assumptions about packages and
>> paths will be accurate.
>>
>> Ideally we should be moving away from any manual run of any script
>> after an installation or upgrade, including postinstall, if that work
>> can be done within the RPM.
>> --
>> Thanks,
>> Jeff
>>
>>
>> On Wed, Jul 19, 2017 at 9:08 AM, Robert Butts <robert.o.bu...@gmail.com>
>> wrote:
>> > It sounds li

Re: Edge Server throughput measure

[Jeff Elsloo]

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 the protocol and uses it to make routing
decisions. Traffic Router uses consistent hashing to help ensure edge
cache efficiency (cache hit ratios). Finally, Traffic Stats pulls data
off Traffic Monitor and inserts it into InfluxDB for analysis
purposes, which can then be charted using Grafana.

Hopefully that helps..
--
Thanks,
Jeff


On Thu, May 11, 2017 at 9:22 AM, Burak Sarp
 wrote:
>  blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
> #715FFA solid !important; padding-left:1ex !important; background-color:white 
> !important; }
> Hi all,
> Is there any way to measure throughput of edge server ?I mean how to create 
> efficient load on edge servers?
> ThanksSarp
> Sent from Yahoo Mail for iPhone

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

[Jeff Elsloo]

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 today if time permits, and I'll bring it up then. It looks like
TC-254 is a duplicate bug with slightly different wording, so I'll
likely merge it with TC-200.

Also, as far as I know, the default values used for delivery service
TTLs are *not* pulled from the setting in config->ttls, which is
parameter driven. They're currently hardcoded in a template. I can
make a note to use the defaults from config->ttls, and fall back to
hardcoded defaults if necessary.

In the meantime, if you need a workaround, you can edit the field
directly in the database and snapshot the CRConfig. This is what we've
been doing, but to be frank, this is a simple bug that we need to fix
ASAP.
--
Thanks,
Jeff


On Mon, May 15, 2017 at 12:48 AM, Ori Finkelman  wrote:
> Hi,
> I am using TC 1.7.
> I have an HTTP delivery service and would like to change the TTL of the A
> records traffic router is responding with,
> When changing the parameters tld.ttls.A or tld.ttls. it has no effect
> on the TTLs passed in the CRConfig.json.  It always stays 3600, which is
> different than the behavior for the tld.ttls.NS which is properly reflected.
> For example, setting
> tld.ttls.A  60
> tld.ttls.   60
> tld.ttls.NS40
>
> Creates the following CRConfig.json
>
> "my-service": {
>   "protocol": {
> "redirectToHttps": "false",
> "acceptHttps": "false"
>   },
>   "domains": ["my-service.my-cdn.my-domain.com"],
>   "missLocation": {
> "long": "-87.627778",
> "lat": "41.881944"
>   },
>   "ttls": {
> "": "3600",
> "SOA": "86400",
> "A": "3600",
> "NS": "40"
>   },
>
> Is there a different configuration I am missing, or it's a known issue ?
>
> Thanks,
> Ori
>
>
>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> o...@qwilt.com

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

[Jeff Elsloo]

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 chain shouldn't be a problem in Traffic
> Ops. Best to make sure server cert is at the top of the chain, and the rest
> of the certs are below, in order, with the CA cert last.
>
> __Jason
>
> On Tue, May 23, 2017 at 2:15 PM, Dave Neuman  wrote:
>
>> Hey Oren,
>> Yes you can enter an externally created, full-chain certificate in Traffic
>> Ops; we do this all the time.  You shouldn't need to do anything special
>> besides make sure that the certificate chain is in the correct order.  I
>> think you need to have the server (wildcard first) then the intermediates,
>> then the root block.  If that doesn't work, I would try reversing the
>> order.
>>
>> --Dave
>>
>> On Tue, May 23, 2017 at 4:45 AM, Oren Shemesh  wrote:
>>
>> > Hi,
>> >
>> > After creating a DS which supports SSL, and using an official certificate
>> > created by GoDaddy (As opposed to a self-signed certificate generated by
>> > Ops), we ran into the following issue:
>> >
>> > An SSL scan from https://www.ssllabs.com/ssltest , done on
>> > tr.., complained about the fact that the server's
>> > certificate chain is incomplete.
>> > (Do try this tool on your servers, you might find the results
>> interesting)
>> >
>> > I tried pasting the full certificate chain (Made from four blocks, each
>> > marked with "-BEGIN CERTIFICATE-" and "-END CERTIFICATE-"
>> > lines) into Ops, but this made the traffic router's situation worse: It
>> > consumed the certificate chain with no problem, but now it presents a
>> > certificate for GoDaddy, instead of a certificate for *
>> > ...
>> > So, I guess that when pasting a certificate for a DS via Ops, it only
>> uses
>> > the first block in the chain.
>> >
>> > A quick check with tomcat documentation shows that in order for it to
>> > present a full-chain certificate, two different 'keytool -import'
>> commands
>> > should be used, one for the 'root' and another for the 'server'  (See
>> > https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#
>> > Importing_the_Certificate
>> > ).
>> > This might explain the problem: Given the current Ops GUI, I am entering
>> a
>> > chain of certificates in one block of text, using it as if it is a
>> 'server'
>> > certificate, instead of breaking it into a 'root' and a 'server'
>> > certificate.
>> >
>> > So after all this, here is my question:
>> >
>> > Is there a way to use an externally-created, full-chain certificate, in
>> > Traffic Ops ?
>> >
>> > Thanks a lot, Oren.
>> >
>> > --
>> >
>> > *Oren Shemesh*
>> > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | or...@qwilt.com
>> > 
>> >
>>

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

[Jeff Elsloo]

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 issues in JIRA that will have to be moved.
I'm -1 on maintaining work items in two separate systems, but +1 on
tracking the roadmap items in one; JIRA or GitHub.

I like the flexibility of a wiki in terms of presentation, but the
information can quickly become outdated. It's a secondary system that
would require manual updates if/when a roadmap item is worked.
--
Thanks,
Jeff


On Thu, May 25, 2017 at 1:51 PM, Dan Kirkwood  wrote:
> I'm also with Dave on using github (preferably not Jira) for tracking
> this..Some enterprising individual could use the github api to
> produce such a report as well showing what's being worked and what
> isn't...
>
> -dan
>
> On Thu, May 25, 2017 at 1:46 PM, Dewayne Richardson  wrote:
>> +1 on tracking the Roadmap on Github, the "Labels" in github will make it
>> easier to track than a wiki (and even JIRA)
>>
>> On Thu, May 25, 2017 at 12:39 PM, Shmulik Asafi  wrote:
>>
>>> I think JIRA/Github are suitable candidates.
>>> It will require to decide on some way to tag these items so a convenient
>>> filter can produce the desired list (otherwise it will be hidden between
>>> lots of JIRAs and no use for anyone)
>>>
>>> What I personally like about the Wiki option, is that maintaining my list
>>> of items will involve only a single page (no mouse clicks); in contrast to
>>> JIRA where I'll need to create items and maintain each item in a separate
>>> page (many mouse clicks). I'm also more of a list-of-open-bullets guy than
>>> a table-with-fixed-columns guy when it comes to viewing information.
>>>
>>> On the other hand JIRA gives more power when it comes to stuff like
>>> order-by filter-by and etc.
>>>
>>> Ultimately, it's a question of which tool most people imagine will be
>>> convenient for them to update and view.
>>>
>>> On Thu, May 25, 2017 at 7:02 PM, Dave Neuman  wrote:
>>>
>>> > I am probably opening a can of worms that I don't know if I want to open,
>>> > but can't we just use Jira for this (and Github once we move there)?  If
>>> > someone is working on something it should be in Jira as an issue that
>>> > assigned to that person.  From there you can see who is working on what.
>>> > It's not going to be perfect, and everything is not always going to be in
>>> > there, but it should be good enough IMO.  I think that would be a better
>>> > solution than relying on people to keep a wiki up to date.
>>> >
>>> > On Thu, May 25, 2017 at 9:54 AM, Durfey, Ryan 
>>> > wrote:
>>> >
>>> > > I am +1 on this.  This dovetails well with the idea of a high-level
>>> > > roadmap illustrating active areas of work.
>>> > >
>>> > > I am open to ideas on what tool to use.  I agree with Shmulik we could
>>> > > make this work in the wiki if needed.
>>> > >
>>> > > Ryan DurfeyM | 303-524-5099
>>> > > CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com>> > > cdn_supp...@comcast.com>
>>> > >
>>> > >
>>> > > From: Shmulik Asafi 
>>> > > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
>>> > > dev@trafficcontrol.incubator.apache.org>
>>> > > Date: Wednesday, May 24, 2017 at 11:54 PM
>>> > > To: "dev@trafficcontrol.incubator.apache.org" <
>>> > > dev@trafficcontrol.incubator.apache.org>
>>> > > Subject: TC Contributers to Publish list of Planned/WIP Items for
>>> Better
>>> > > Community Sync
>>> > >
>>> > > Hi All,
>>> > >
>>> > > During the summit I've suggested to a few people that maybe each TC
>>> > > contributer should publish a list of the items she's working on
>>> presently
>>> > > and planning to work on in the near future.
>>> > >
>>> > > The goal is to share what "major stuff" is going to happen in the
>>> project
>>> > > (e.g. Jeff's work on Localized/Edge Traffic Routing; Derek's work on
>>> > > Delivery Service configuration; Dave/Matt's work on Lua scripts; etc.).
>>> > >
>>> > > I think this is very little effort by each contributer and will allow
>>> us
>>> > to
>>> > > be much more synced, make it possible to engage with existing efforts
>>> and
>>> > > provide a platform to detect conflicting/duplicated efforts. I also
>>> think
>>> > > this can be a first baby step towards building a roadmap in the long
>>> > term.
>>> > >
>>> > > The few people I talked with seemed open to this idea. I hope others
>>> will
>>> > > feel the same.
>>> > >
>>> > > I think Wiki pages is the best place for this, but it can also be in
>>> > > JIRA/Git, or whatever appropriate tools Apache provides (it would also
>>> be
>>> > > cool if we could make RSS feed no changes).
>>> > >
>>> > > What do you think?
>>> > >
>>> > > If all support, I'd be happy to 

Re: [VOTE] Move Traffic Control to full GitHub

[Jeff Elsloo]

+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
>> mentioned that we can now move to "full" GitHub. Some more information in
>> that thread if you are not familiar. I would like to call an official vote
>> on that.
>>
>> This vote will be open for at least 72 hours.
>>
>>  [ ] +1 Move Traffic Control to use full GitHub
>>  [ ]  0 No opinion
>>  [ ] -1 Do not Move Traffic Control to use full GitHub because...
>>
>> Rgds,
>> JvD

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

[Jeff Elsloo]

+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-trafficcontrol/compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC3
>
> This corresponds to git:
> Hash: 795ea3adf2003dd27523b6b9ff4691f23d41ce30
> Tag: RELEASE-2.0.0-RC3
>
> Which can be verified with the following:git tag -v RELEASE-2.0.0-RC3
>
> My code signing key is available here:
> http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
>
> and here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha512 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC3
>
>
> The vote will remain open until Thursday, June 8, 2017.
>
> This RC fixes some packaging issues in RC2, there are no other changes. The 
> git tag hash is the same, but due to changes in the tarball the release 
> signatures HAVE changes.
>
> Thanks,
> Eric Friedrich

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

[Jeff Elsloo]

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-trafficcontrol/compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC2
>
> This corresponds to git:
>  Hash: 795ea3adf2003dd27523b6b9ff4691f23d41ce30
>  Tag: RELEASE-2.0.0-RC2
>
> Which can be verified with the following:git tag -v RELEASE-2.0.0-RC2
>
> My code signing key is available here:
> http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
>
> and here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha512 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC2
>
>
> The vote will remain open until Tuesday, June 6, 2017.
>
> Thanks!
> Eric Friedrich
>

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

[Jeff Elsloo]

+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-trafficcontrol/compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC4
>
> This corresponds to git:
> Hash: 795ea3adf2003dd27523b6b9ff4691f23d41ce30
> Tag: RELEASE-2.0.0-RC4
>
> Which can be verified with the following:git tag -v RELEASE-2.0.0-RC4
>
> My code signing key is available here:
> http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
>
> and here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha512 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC4
>
>
> The vote will remain open until Thursday, June 8, 2017.
>
> This RC fixes some packaging issues in RC2 and RC3, there are no other 
> changes. The git tag hash is the same, but due to changes in the tarball the 
> release signatures HAVE changes.
>
> Thanks,
> Eric Friedrich

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

[Jeff Elsloo]

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-trafficcontrol/compare/RELEASE-1.8.0...RELEASE-1.8.1-RC0
>
> This corresponds to git:
>   Hash: cc56e76320f6d63f611d4070a1aca1e82d235a61
>   Tag: RELEASE-1.8.1-RC0
>
> Which can be verified with the following:git tag -v RELEASE-1.8.1-RC0
>
> My code signing key is available here:
> http://pgp.mit.edu/pks/lookup?op=get=0xC4B33C804587A8F0
>
> and here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha512 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0
>
> This release updates the Java version used to build traffic monitor and 
> traffic
> router and updates a javascript library to display tables in traffic ops.
>
> The vote will remain open until Monday, June 5, 2017.
>
> Thanks!

Re: DNSSEC in Traffic Router

[Jeff Elsloo]

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 the CDN and
the DNS delegation point, as it relates to DNSSEC. You can generate
keys for the CDN under Tools -> Manage DNSSEC Keys; once generated,
you should see data, and more specifically, the data around "DS Record
Information" is what's important. This represents the DS RR type and a
DS record with the data shown on this screen goes into the parent
domain's zone, at the delegation point for your CDN.

For example, if you delegate cdn.example.com to a Traffic Control
system, Traffic Router is authoritative for that entire domain. You
would need to work with the owners of example.com to insert a DS
record with this information. The record itself would exist in
example.com, and would look something like:

cdn.example.com IN DS  Y Z DIGEST

..where  is the key ID (auto generated), Y is the algorithm, Z is
the digest type, and DIGEST is the digest in hex.

If you want to enable DNSSEC familiarize yourself with the operational
best practices, documented in RFC 6781 and the key rollover timing
considerations documented in RFC 7583. You will need to know what a
KSK and ZSK are, how they relate to DNSKEY and DS RR types, and
understand how you "roll" the KSK at the delegation point. KSKs that
Traffic Control generates are generally good for one year, so that
means you should roll the CDN's KSK annually.

We used the pre-publish strategy for our 2016 key roll and will be
doing the same this year when the time comes. This means creating a
KSK that's effective in the future, which is published but not used to
sign records. You can do this by using the "Regenerate KSK" button on
the management screen and setting the effective date to one in the
future to allow resolvers to get a new copy of DNSKEYs and DS records
prior to the actual effective date. Traffic Router uses the effective
date to know which key to sign RR sets with, so it won't actually use
the new key until the effective date.

When testing a DNSSEC implementation, it's important to test and
understand the relationship between each zone and RR type. There are
two sites I use for this:

http://dnsviz.net/
http://dnssec-debugger.verisignlabs.com/

..these sites will help you identify why DNSSEC validation might be
failing, which manifests only as a SERVFAIL at the client side, which
isn't very helpful.
--
Thanks,
Jeff


On Wed, Sep 27, 2017 at 10:40 AM, Amir Yeshurun  wrote:
> Hello dev list.
>
> To avoid DNS cache pollusion, I would like to use DNSSEC, so that TR sign
> cdn- domain A records.
>
> The docs say that this feafure is only available for DNS based delivery
> services.
>
> My delivery services are HTTP.
>
> I would like to understand what are the gaps to fill in order to have
> DNSSEC support in HTTP delivery services.
>
> Thanks
> /amiry

Re: Preventing routing to individual caches

[Jeff Elsloo]

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 Monitor and Traffic Router aware of the new
status. Something like MONITOR_ONLY might make sense. If we did this
in Traffic Ops, we could use the new status to control whether DS
assignments occur in the Traffic Ops APIs (legacy CRConfig and
monitoring/routing config APIs). Making the change in Traffic Ops is
likely to be less work and will be less disruptive to production
traffic (no deployment of TR required).

The specific reason why this is tricky is that we want to poll astats
to collect metrics off these caches using Traffic Monitor, assign
delivery services to them, but not route traffic to them. That implies
that the caches must be in the CRConfig in order for Traffic Monitor
to see them, but due to the DS assignments, Traffic Router will route
traffic to them. The caches in question already have a unique type,
"EDGE_FOO" for example, while our regular edges are simply "EDGE."

A while back, I worked on a change to allow us to monitor any server
type that begins with EDGE or MID, which gets them into the CRConfig.
This worked fine until we had a need to map DSs to the edge type in
question. With the golang version of Traffic Monitor we moved toward
monitoring.json, but we still rely on CRConfig. Long term we should
complete that move, and update Traffic Router to consume the routing
config so that the two configs of the components aren't so tightly
coupled. That would allow us to accomplish this sort of thing much
more easily and clearly.
--
Thanks,
Jeff


On Wed, Aug 23, 2017 at 3:53 PM, rawlin.pet...@gmail.com
 wrote:
> What about the server status CCR_IGNORE ("Server is ignored by traffic 
> router.") that already exists? It doesn't appear to be checked when 
> generating CRConfig right now, but maybe it should be?
>
> --Rawlin
>
> On 2017-08-22 11:45, "Gelinas, Derek"  wrote:
>> I’d agree with you if this was designed to drain, but this is intended as a 
>> permanent state for a pretty good long list of caches.
>>
>> DG
>>
>> > On Aug 22, 2017, at 1:28 PM, Eric Friedrich (efriedri) 
>> >  wrote:
>> >
>> > What about a modification of option 1- adding a new state per server.
>> >
>> > Instead of ADMIN_DOWN, it could be “REPORTED_DRAIN” to indicate the 
>> > difference
>> >
>> > —Eric
>> >
>> >> On Aug 22, 2017, at 1:14 PM, Gelinas, Derek  
>> >> wrote:
>> >>
>> >> That’s actually the workaround we’re using at the moment - setting them 
>> >> to admin_down.  That’s a temporary measure, though - we want something 
>> >> more permanent.
>> >>
>> >> DG
>> >>> On Aug 22, 2017, at 1:09 PM, Eric Friedrich (efriedri) 
>> >>>  wrote:
>> >>>
>> >>> How does your use case differ from marking a server as offline in 
>> >>> Traffic Ops and snapshotting?
>> >>>
>> >>> Thats the easiest way I can think of to get a server in this state
>> >>>
>> >>> —Eric
>> >>>
>>  On Aug 22, 2017, at 1:00 PM, Gelinas, Derek  
>>  wrote:
>> 
>>  We’ve run across a situation in which we need certain caches to 
>>  simultaneously have map rules for a delivery service, but not actually 
>>  have those caches routed to when requests are made via traffic router.  
>>  Essentially, this means removing the delivery service from the cache’s 
>>  info in the crconfig file.
>> 
>>  There’s been a bit of internal debate about the best ways to do this, 
>>  and I’d like to collect some opinions on the matter.
>> 
>>  1) Server table flag - when marked, nothing is routed to the host at 
>>  all.  Not as configurable as option 3, but more so than option 2.  
>>  Faster than option 2 as it would be returned with existing search 
>>  results and could be easily filtered on.  Minor UI change only.
>>  2) Profile parameter - when marked, nothing is routed to any host with 
>>  this profile.  Heavy handed, and would require additional profile 
>>  parameter lookups when generating the crconfig, so it’d slow it down. 
>>  No UI change.
>>  3) deliveryservice_servers table flag - an additional column that is 
>>  true by default.  When desired, the user could pull up a sub-window 
>>  within the delivery service configuration that would present a list of 
>>  the hosts which have been assigned to the delivery service (and are not 
>>  of org type).  The user could deselect the desired hosts, setting the 
>>  DSS routing value to false.  This server would then be ignored when 
>>  generating the crconfig data for that specific delivery service.  This 
>>  would be the most configurable option, and 

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

[Jeff Elsloo]

+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
> 3 +1 PPMC votes are cast.
>
> [ ] +1 Approve the release
>
> [ ] -1 Do not release this package because ...
>
> Changes since 2.1.0:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-2.1.0...RELEASE-2.2.0-RC6
>
> This corresponds to git:
>  Hash: 8f4d1ee2aa25000a9d0e17bbf85286c4a7264eab
>  Tag: RELEASE-2.2.0-RC6
>
> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC6
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), md5 and sha1 checksums are provided here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC6
>
>
>
> Thanks!

Re: Anonymous IP Blocking Flowchart

[Jeff Elsloo]

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 realized the first diagram I put up was outdated
>
> The response to anonymous IP blocking is actually configurable between a 
> slate (302 redirect to a new URL) and a 403
>
> —Eric
>
>> On Oct 19, 2017, at 10:53 AM, Eric Friedrich (efriedri)  
>> wrote:
>>
>> Here is flowchart requested at the summit. I’ll put this diagram along with 
>> the rest of the slides up soon
>>
>> Its a link to a PNG despite the horribly formatted URL
>> https://cisco.box.com/s/4rwd6kk069vdmzxpp2ak0vt2elds0ufc
>>
>> —Eric
>>
>>
>

Re: Promote Golang Traffic Monitor to Default

[Jeff Elsloo]

Hi all,

Apologies for the delay, and thanks to Rob for submitting PR 1427 to
take care of this. I just merged his PR and that means that
`traffic_monitor` has been renamed to `traffic_monitor_java` and
`traffic_monitor_golang` has been renamed to `traffic_monitor` (thanks
Rob!). This means that we are now one step closer to formally retiring
the Java version of Traffic Monitor.

Before proposing a vote, I'd like to get a feel for how quickly we can
do the formal retirement. We're currently working on 2.1 so that means
that we could retire it as early as 2.2. If we want 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 <els...@apache.org> wrote:
> It sounds like we do not have any -1s on this, so I'm going to assume
> we're good to make this change. I have some other things to focus on
> at the moment, but will try to get this done as time permits. I'll
> send another email out with details when I go to make the change, and
> will allow some time before pushing anything in case someone has
> concerns.
> --
> Thanks,
> Jeff
>
>
> On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <neu...@apache.org> wrote:
>> +1 on the rename
>>
>> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <j...@knutsel.com> wrote:
>>
>>> +1
>>>
>>> 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
>>> >
>>> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <els...@apache.org> wrote:
>>> >
>>> > > For the most part, it's a drop in replacement for the Java version,
>>> > > and based on our own experience it seems to work exactly as the Java
>>> > > version would, including co-existence. There is a TO API dependency
>>> > > for monitoring.json that the Java version does not have, and I'm not
>>> > > sure what the history is with that endpoint and how far back we could
>>> > > remain compatible. Traffic Router does not care what version of
>>> > > Traffic Monitor it talks to, as the format of cr-states.json has not
>>> > > changed. Same goes for TM and ATS. I believe we had co-existence
>>> > > running in production going back to the 1.8.x releases.
>>> > >
>>> > > Keep in mind that the intent is to drive users toward using the Golang
>>> > > component by default starting with the 2.1.0 (or maybe 2.2.0?) release
>>> > > while still allowing one to build, run, or contribute to the Java
>>> > > version until our next major release (3.0.0). The intent is not to
>>> > > give people a drop in replacement that works with prior versions; we
>>> > > have not tested that thoroughly across all versions, and while it
>>> > > might work, we should think of the Golang Traffic Monitor as a 2.0.x
>>> > > and onward component. I think that statement holds for most of our
>>> > > components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
>>> > > Traffic Ops system. 1.7 is ancient, and have we ever really done
>>> > > backward compatibility testing with versions?
>>> > >
>>> > > To this end, if we do decide to make the Golang version the default in
>>> > > the future, at a minimum we will need to provide release notes that
>>> > > explain how to convert the Java configuration to the Golang version's
>>> > > config. Ideally we would provide a simple script to convert the
>>> > > configuration for our users, potentially running it as a postinstall
>>> > > scriptlet in the RPM if the Java version is already installed.
>>> > > Theoretically we could `yum upgrade traffic_monitor` and seamlessly
>>> > > move from Java to Golang.
>>> > > --
>>> > > Thanks,
>>> > > Jeff
>>> > >
>>> > >
>>> > > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
>>> > > <efrie...@cisco.com> wrote:
>>> > > > I think I remember Rob making this point in Miami, but all of TMs
>>> APIs
>>> > > (REST, CRConfig, Health.json, etc…) are identical between the

Re: Golang Proxy Validation Dependencies

[Jeff Elsloo]

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 is a concerning performance penalty.

As Dewayne said, create, update and delete actions represent a tiny
fraction of the overall requests into TO. Given that the majority of
these actions are performed by humans, I would be shocked if there was
a perceptible performance difference with the reflection based
validation in place. It's not like we're trying to validate enormous
and complex objects here; we're talking 20 fields or so for any given
post.

I'm +1 on using validation libraries such as these even if they use
reflection, provided that we do not see dramatic changes in
performance. I think that's highly unlikely in this case.
--
Thanks,
Jeff


On Thu, Jan 11, 2018 at 10:07 AM, Chris Lemmons  wrote:
> True, but how many of those out-of-the-box checks are both useful and
> relevantly complex?
>
> To me, the cool part of ozzo is the way it collects the output and
> formats it. That's unfortunately also the computationally expensive
> part.
>
> On Thu, Jan 11, 2018 at 9:49 AM, Dewayne Richardson  wrote:
>> Please keep in mind that we do not Create/Update/Delete very often in
>> Traffic Ops, so the performance penalty for Validation should be taken into
>> consideration.  I also don't want to re-invent all of those out-of-the-box
>> field level checks by hand when I can just use them from here:
>> https://github.com/asaskevich/govalidator#list-of-functions
>>
>> -Dew
>>
>> On Thu, Jan 11, 2018 at 9:24 AM, Chris Lemmons  wrote:
>>
>>> I like the output style, but I'm a bit concerned on the performance
>>> front. ozzo appears to do all it's magic with heavy use of reflection,
>>> which is often a slow spot in go. Most places, it wouldn't matter
>>> much, but this will be called on every element of every API function,
>>> so a nod toward performance may be in order. Have we done some
>>> measurement to see whether this adds a relevant amount of overhead to
>>> the calls? Or are the calls still dominated by the DB lookup?
>>>
>>> Relatedly, is this a major advantage over something like this:
>>>
>>> if ds.Active == nil { errMsgs = append(errMsgs, `"active" must be
>>> provided`) }
>>>
>>> On Thu, Jan 11, 2018 at 8:49 AM, Dewayne Richardson 
>>> wrote:
>>> > We've been moving along with more functionality in the Golang proxy,
>>> mostly
>>> > the Read's up until now, comparatively TO does much fewer Create/Updates.
>>> > Our current task is to circle back and start implementing the (C)reate,
>>> > (U)pdate, and (D)eletes.  One of the obvious needs for the this task are
>>> > validation rules.  I've been doing research to figure out the cleanest
>>> and
>>> > most maintainable way to rewrite the Perl validation rules in Go.
>>> >
>>> > TC Issue for tracking
>>> > https://github.com/apache/incubator-trafficcontrol/issues/1756
>>> >
>>> > These are the two dependencies I'd like to leverage and provide feedback:
>>> >
>>> > Both are MIT Licenses
>>> > Uses normal programming constructs rather than error-prone struct tags to
>>> > specify how data should be validated.
>>> > https://github.com/go-ozzo/ozzo-validation
>>> > https://github.com/go-ozzo/ozzo-validation/blob/master/LICENSE
>>> >
>>> > Core Validation library that the prior library uses that has a lot of
>>> > useful convenience methods that I'd rather not re-invent
>>> > https://github.com/asaskevich/govalidator
>>> > https://github.com/asaskevich/govalidator#list-of-functions
>>> > https://github.com/asaskevich/govalidator/blob/master/LICENSE
>>> >
>>> > And here is how I've used these as sample validation rules that I've
>>> > implemented as a POC:
>>> >
>>> > https://github.com/dewrich/incubator-trafficcontrol/blob/
>>> tor-api-ds/traffic_ops/traffic_ops_golang/deliveryservice/
>>> deliveryservices.go#L93
>>> >
>>> > Existing Mojo Perl Rules for comparison.
>>> > https://github.com/apache/incubator-trafficcontrol/blob/
>>> master/traffic_ops/app/lib/API/Deliveryservice.pm#L1363
>>> >
>>> >
>>> > -Dew
>>>

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

[Jeff Elsloo]

-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 release for v2.2.0-RC0
>
> The vote is open for at least 72 hours and passes if a majority of at least
> 3 +1 PPMC votes are cast.
>
> [ ] +1 Approve the release
>
> [ ] -1 Do not release this package because ...
>
> Changes since 2.1.0:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-2.1.0...RELEASE-2.2.0-RC0
>
> This corresponds to git:
>  Hash: 9730e9a25e9e665a0873d2f2fb04c97491e60131
>  Tag: RELEASE-2.2.0-RC0
>
> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC0
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=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), md5 and sha1 checksums are provided here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC0/
>
> Thanks!

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

[Jeff Elsloo]

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 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 <r...@apache.org> wrote:
>> Hello All,
>>
>> I've prepared a release for v2.2.0-RC0
>>
>> The vote is open for at least 72 hours and passes if a majority of at least
>> 3 +1 PPMC votes are cast.
>>
>> [ ] +1 Approve the release
>>
>> [ ] -1 Do not release this package because ...
>>
>> Changes since 2.1.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-2.1.0...RELEASE-2.2.0-RC0
>>
>> This corresponds to git:
>>  Hash: 9730e9a25e9e665a0873d2f2fb04c97491e60131
>>  Tag: RELEASE-2.2.0-RC0
>>
>> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC0
>>
>> My code signing key is available here:
>> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=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), md5 and sha1 checksums are provided here:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC0/
>>
>> Thanks!

Re: Traffic Router Enhancement - Default Maxmind Geolocation Override

[Jeff Elsloo]

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, but as long as there are distinct conditions where we can 
> determine that a response is a default, we can expand this enhancement in the 
> future to work with other DBs as well.
>
> -Jesse
>
> On 2/19/18, 7:11 AM, "Nir Sopher"  wrote:
>
> Are you familiar with the behavior of other ip to geo DBs?
> Anyway +1 from me.
> I would also be happy to review and merge.
> Nir
>
> On Feb 16, 2018 18:22, "Rivas, Jesse"  wrote:
>
> > If there are no objections to the proposed enhancement for a MaxMind
> > override location on a per country, per CDN basis, then I will move 
> forward
> > with the changes and work with a committer to get the PR merged.
> >
> > -Jesse
> >
> > On 2/15/18, 8:37 AM, "Eric Friedrich (efriedri)" 
> > wrote:
> >
> > Sounds great, thanks!
> >
> > > On Feb 15, 2018, at 10:33 AM, Rivas, Jesse 
> 
> > wrote:
> > >
> > > Eric,
> > >
> > > We can determine a response from MaxMind is a default location 
> when
> > the following conditions are met: the country code is populated, the 
> city
> > is null, the postal code is null, and the subdivisions list is empty. If
> > these conditions are met, we check for an instance of
> > maxmind.default.override with the same country code. This allows users 
> to
> > have one MaxMind override per country, per CDN.
> > >
> > > -Jesse
> > >
> > > On 2/15/18, 6:04 AM, "Eric Friedrich (efriedri)" 
> 
> > wrote:
> > >
> > >How does the suggested fix know when maxmind is returning a
> > “default location” versus an actual location?
> > >
> > >Hopefully the solution is applicable to CDNs which are spread
> > across multiple countries and geographies?
> > >
> > >—Eric
> > >
> > >> On Feb 13, 2018, at 1:34 PM, Rawlin Peters 
> 
> > wrote:
> > >>
> > >> Yeah, this basically solves the problem where MaxMind knows a 
> client
> > >> is in the US (or another country) but doesn't know the state, 
> city,
> > >> zip, etc., so it's not a "true" miss. In that case MaxMind 
> returns
> > the
> > >> geographic center of that country as the client's location, but 
> we
> > >> don't want to route those clients to the cache group closest to 
> that
> > >> location because it might not be the ideal cachegroup. By using 
> this
> > >> parameter we can shift this high volume of "US" traffic that is
> > >> essentially being localized to a lake in Kansas to a cachegroup 
> more
> > >> capable of handling that load. And we can do this on a 
> per-country
> > >> basis because we can create multiple of these parameters (which 
> we
> > >> wouldn't be able to do if we just used the Default Miss Lat/Lon 
> of a
> > >> DeliveryService).
> > >>
> > >> -Rawlin
> > >>
> > >> On Tue, Feb 13, 2018 at 11:10 AM, Rivas, Jesse <
> > jesse_ri...@comcast.com> wrote:
> > >>> Steve,
> > >>>
> > >>> Using the miss location for the DS was a potential solution that
> > we talked about. However, the miss location is intended for use when the
> > client IP falls through MaxMind without any data. Since the default
> > location doesn't fit this criteria, it was decided to use a profile
> > parameter to preserve granularity.
> > >>>
> > >>> Jesse
> > >>>
> > >>> On 2/13/18, 11:06 AM, "Steve Malenfant" 
> > wrote:
> > >>>
> > >>>   Jesse,
> > >>>
> > >>>   I'm not exactly sure how MaxMind return this default value but
> > would there
> > >>>   be a way to use the MISS location specified in the DS? Seems
> > like that is
> > >>>   what it was intended for.
> > >>>
> > >>>   Steve
> > >>>
> > >>>   On Tue, Feb 13, 2018 at 12:42 PM, Rivas, Jesse <
> > jesse_ri...@comcast.com>
> > >>>   wrote:
> > >>>
> >  Hi all,
> > 
> > 
> > 
> >  At Comcast, we have been seeing a pattern of the same cache 
> group
> > being
> >  overloaded nightly as traffic increases on the CDN. The cause 
> was
> >  determined to be a default location that the geolocation 
> provider
> > MaxMind
> >  

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

[Jeff Elsloo]

+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 clean Centos 7 VM
> - postinstall properly configures
> - a couple of basic traffiic_ops calls return proper json output
>
>
> On Mon, Apr 9, 2018 at 3:58 PM, David Neuman 
> wrote:
>
>> +1
>> I tested the following:
>> - building with the pkg command
>> - signatures
>> - checksums (were we supposed to get rid of md5?  I must have missed that)
>> - installed and started traffic_stats
>>
>>
>> On Wed, Apr 4, 2018 at 11:04 AM, Robert Butts  wrote:
>>
>> > Hello All,
>> >
>> > I've prepared a release for v2.2.0-RC4
>> >
>> > The vote is open for at least 72 hours and passes if a majority of at
>> least
>> > 3 +1 PPMC votes are cast.
>> >
>> > [ ] +1 Approve the release
>> >
>> > [ ] -1 Do not release this package because ...
>> >
>> > Changes since 2.1.0:
>> > https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-2.1.0
>> .
>> > ..
>> > RELEASE-2.2.0-RC4
>> >
>> > This corresponds to git:
>> >  Hash: 45151f8e518fe92dfa64c7311b877cb13299debc
>> >  Tag: RELEASE-2.2.0-RC4
>> >
>> > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC4
>> >
>> > My code signing key is available here:
>> > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
>> >
>> > Make sure you refresh from a key server to get all relevant signatures.
>> >
>> > The source .tar.gz file, pgp signature (.asc signed with my key from
>> > above), and sha512 checksum are provided here:
>> >
>> > https://dist.apache.org/repos/dist/dev/incubator/
>> trafficcontrol/2.2.0/RC4
>> >
>> >
>> >
>> > Thanks!
>> >
>>

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

[Jeff Elsloo]

+1
--
Thanks,
Jeff


On Mon, Apr 2, 2018 at 2:53 PM, Dan Kirkwood <dang...@gmail.com> wrote:
> +1
>
> On Mon, Apr 2, 2018 at 2:12 PM, Dave Neuman <neu...@apache.org> wrote:
>
>> +1
>>
>> On Mon, Apr 2, 2018 at 2:11 PM, David Neuman <david.neuma...@gmail.com>
>> wrote:
>>
>> > Dear Traffic Control community members:
>> >
>> > I would like to call a vote on the resolution for Traffic Control to
>> > graduate from to an Apache TLP.  We have already voted on whether or not
>> we
>> > should start the graduation process [1] and this is the next step.
>> Please
>> > see the resolution below and vote as follows:
>> >
>> > [ ] +1 Graduate Traffic Control from the incubator
>> > [ ] +0 No Opinion
>> > [ ] -1 Do not graduate Traffic Control from the incubator (please provide
>> > a reason)
>> >
>> > The vote is open for a minimum of 72 hours and will need at least 3 more
>> > +1 votes than -1 votes from PMC members to succeed.
>> >
>> > If this VOTE succeeds, a similar VOTE will be started on the
>> > gene...@incubator.apache.org mailing list. If that VOTE succeeds, a
>> > resolution will be included in the next Apache Board Meeting.
>> >
>> > Please feel free to reach out with any questions.
>> >
>> > Thanks,
>> > Dave
>> >
>> > [1] https://lists.apache.org/thread.html/fb1fae0785feb6568cef6deb6fa207
>> > 23eba54ed63a445462d44564d3@%3Cdev.trafficcontrol.apache.org%3E
>> >
>> > -
>> >
>> > Establish the Apache Traffic Control Project
>> >
>> > WHEREAS, the Board of Directors deems it to be in the best interests of
>> > the Foundation and consistent with the Foundation's purpose to establish
>> > a Project Management Committee charged with the creation and maintenance
>> > of open-source software, for distribution at no charge to the public,
>> > related to building, monitoring, configuring, and provisioning a large
>> > scale content delivery network (CDN)..
>> >
>> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
>> > (PMC), to be known as the "Apache Traffic Control Project", be and
>> > hereby is established pursuant to Bylaws of the Foundation; and be it
>> > further
>> >
>> > RESOLVED, that the Apache Traffic Control Project be and hereby is
>> > responsible for the creation and maintenance of software related to
>> > building, monitoring, configuring, and provisioning a large scale
>> > content delivery network (CDN).; and be it further
>> >
>> > RESOLVED, that the office of "Vice President, Apache Traffic Control" be
>> > and hereby is created, the 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 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 Traffic Control
>> > Project:
>> >
>> >  * Dan Kirkwood   <dang...@apache.org>
>> >  * David Neuman   <neu...@apache.org>
>> >  * Dewayne Richardson <dewr...@apache.org>
>> >  * Eric Covener   <cove...@apache.org>
>> >  * Eric Friedrich <fri...@apache.org>
>> >  * Hank Beatty<hbea...@apache.org>
>> >  * Jan van Doorn  <j...@apache.org>
>> >  * Jeff Elsloo<els...@apache.org>
>> >  * Jeremy Mitchell<mitchell...@apache.org>
>> >  * Leif Hedstrom  <zw...@apache.org>
>> >  * Mark Torluemke <mtorlue...@apache.org>
>> >  * Phil Sorber<sor...@apache.org>
>> >  * Steve Malenfant<smalenf...@apache.org>
>> >
>> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that David Neuman be appointed
>> > to the office of Vice President, Apache Traffic Control, to serve in
>> > accordance with and subject to the direction of the Board of Directors
>> > and the Bylaws of the Foundation until death, resignation, retirement,
>> > removal or disqualification, or until a successor is appointed; and be
>> > it further
>> >
>> > RESOLVED, that the initial Apache Traffic Control PMC be and hereby is
>> > tasked with the creation of a set of bylaws intended to encourage open
>> > development and increased participation in the Apache Traffic Control
>> > Project; and be it further
>> >
>> > RESOLVED, that the Apache Traffic Control Project be and hereby is
>> > tasked with the migration and rationalization of the Apache Incubator
>> > Traffic Control podling; and be it further
>> >
>> > RESOLVED, that all responsibilities pertaining to the Apache Incubator
>> > Traffic Control podling encumbered upon the Apache Incubator PMC are
>> > hereafter discharged.
>> >
>> >
>> >
>>