[jira] [Commented] (TC-391) Mid Tier Thundering Herd Overwhelms Origin when Origin Slow to Respond

[Ryan Durfey (JIRA)]

[ 
https://issues.apache.org/jira/browse/TC-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128683#comment-16128683
 ] 

Ryan Durfey commented on TC-391:


After a lot of research this is more likely on the ATS side.  This ticket is 
being closed.

> Mid Tier Thundering Herd Overwhelms Origin when Origin Slow to Respond
> --
>
> Key: TC-391
> URL: https://issues.apache.org/jira/browse/TC-391
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Ryan Durfey
>  Labels: origin, thundering_herd
>
> Mid tier groups typically send one request per object to origin.  We have 
> noticed that when an origin is slow to respond or sends errors that the mid 
> tier sometimes sends many requests at a high TPS rate which causes a slow 
> origin to fail.
> We are investigating this on both the ATS and ATC side.  We are considering 
> tuning the mid tier retry attempts as well as some other configuration 
> settings to reduce the potential for overload.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TC-391) Mid Tier Thundering Herd Overwhelms Origin when Origin Slow to Respond

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey closed TC-391.
--
Resolution: Not A Problem

Issue is on ATS side, not ATC.

> Mid Tier Thundering Herd Overwhelms Origin when Origin Slow to Respond
> --
>
> Key: TC-391
> URL: https://issues.apache.org/jira/browse/TC-391
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Ryan Durfey
>  Labels: origin, thundering_herd
>
> Mid tier groups typically send one request per object to origin.  We have 
> noticed that when an origin is slow to respond or sends errors that the mid 
> tier sometimes sends many requests at a high TPS rate which causes a slow 
> origin to fail.
> We are investigating this on both the ATS and ATC side.  We are considering 
> tuning the mid tier retry attempts as well as some other configuration 
> settings to reduce the potential for overload.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TC-506) Traffic Ops - SSL Cert Expiration Monitoring for Active Services

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-506:
--

 Summary: Traffic Ops - SSL Cert Expiration Monitoring for Active 
Services
 Key: TC-506
 URL: https://issues.apache.org/jira/browse/TC-506
 Project: Traffic Control
  Issue Type: Bug
  Components: Traffic Ops
Reporter: Ryan Durfey


With all services moving towards SSL there will be a constant battle to keep 
SSL certificates up to date for active services.  Traffic Ops should 
incorporate an internal monitor for upcoming expirations based on the actual 
cert source of record.  This could be a part of the delivery service 
configuration data and would also be useful to customers to examine when certs 
expire.

1. Record or read SSL cert expiration and put into configuration data
2. Allow users access to this data through the API
3. Provide a monitor that runs on a cron to look for certs that expire soon.
4. Alert root operators daily on upcoming expirations



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-496) Monthly Report Generation Automation and API Endpoint

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-496:
---
Description: 
We need a method to schedule regular CDN service reports to be emailed out from 
the traffic portal/traffic ops.  The long term vision is to allow customers to 
schedule email delivery of any report they can view in the portal. 

In the short term, we have to email monthly summary reports of each service 
with summary metrics to customers.  We need a method to schedule the 
generations of these monthly summaries so we are not manually building 100's of 
reports.

Currently these reports consist of going into the portal for each service and 
setting the start and end date for 00:00:00 GMT at the start and end of the 
month and then viewing all charts and summary metrics.

We need an automated method of generating these in an emailable format like PDF.

See https://cwiki.apache.org/confluence/display/TC/Reporting for expanded 
discussion of use case.

  was:
We need a method to schedule regular CDN service reports to be emailed out from 
the traffic portal/traffic ops.  The long term vision is to allow customers to 
schedule email delivery of any report they can view in the portal. 

In the short term, we have to email monthly summary reports of each service 
with summary metrics to customers.  We need a method to schedule the 
generations of these monthly summaries so we are not manually building 100's of 
reports.

Currently these reports consist of going into the portal for each service and 
setting the start and end date for 00:00:00 GMT at the start and end of the 
month and then viewing all charts and summary metrics.

We need an automated method of generating these in an emailable format like PDF.


> Monthly Report Generation Automation and API Endpoint
> -
>
> Key: TC-496
> URL: https://issues.apache.org/jira/browse/TC-496
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API, Traffic Portal
>Reporter: Ryan Durfey
>  Labels: api, reporting
>
> We need a method to schedule regular CDN service reports to be emailed out 
> from the traffic portal/traffic ops.  The long term vision is to allow 
> customers to schedule email delivery of any report they can view in the 
> portal. 
> In the short term, we have to email monthly summary reports of each service 
> with summary metrics to customers.  We need a method to schedule the 
> generations of these monthly summaries so we are not manually building 100's 
> of reports.
> Currently these reports consist of going into the portal for each service and 
> setting the start and end date for 00:00:00 GMT at the start and end of the 
> month and then viewing all charts and summary metrics.
> We need an automated method of generating these in an emailable format like 
> PDF.
> See https://cwiki.apache.org/confluence/display/TC/Reporting for expanded 
> discussion of use case.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-496) Monthly Report Generation Automation and API Endpoint

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-496:
---
Labels: api reporting  (was: )

> Monthly Report Generation Automation and API Endpoint
> -
>
> Key: TC-496
> URL: https://issues.apache.org/jira/browse/TC-496
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API, Traffic Portal
>Reporter: Ryan Durfey
>  Labels: api, reporting
>
> We need a method to schedule regular CDN service reports to be emailed out 
> from the traffic portal/traffic ops.  The long term vision is to allow 
> customers to schedule email delivery of any report they can view in the 
> portal. 
> In the short term, we have to email monthly summary reports of each service 
> with summary metrics to customers.  We need a method to schedule the 
> generations of these monthly summaries so we are not manually building 100's 
> of reports.
> Currently these reports consist of going into the portal for each service and 
> setting the start and end date for 00:00:00 GMT at the start and end of the 
> month and then viewing all charts and summary metrics.
> We need an automated method of generating these in an emailable format like 
> PDF.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TC-496) Monthly Report Generation Automation and API Endpoint

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-496:
--

 Summary: Monthly Report Generation Automation and API Endpoint
 Key: TC-496
 URL: https://issues.apache.org/jira/browse/TC-496
 Project: Traffic Control
  Issue Type: New Feature
  Components: Traffic Ops API, Traffic Portal
Reporter: Ryan Durfey


We need a method to schedule regular CDN service reports to be emailed out from 
the traffic portal/traffic ops.  The long term vision is to allow customers to 
schedule email delivery of any report they can view in the portal. 

In the short term, we have to email monthly summary reports of each service 
with summary metrics to customers.  We need a method to schedule the 
generations of these monthly summaries so we are not manually building 100's of 
reports.

Currently these reports consist of going into the portal for each service and 
setting the start and end date for 00:00:00 GMT at the start and end of the 
month and then viewing all charts and summary metrics.

We need an automated method of generating these in an emailable format like PDF.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-185) postinstall doesn't run due to missing perl module

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-185:
--

Assignee: Dan Kirkwood

> postinstall doesn't run due to missing perl module
> --
>
> Key: TC-185
> URL: https://issues.apache.org/jira/browse/TC-185
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
> Environment: CentOS 7
>Reporter: Hank Beatty
>Assignee: Dan Kirkwood
>Priority: Minor
> Fix For: 2.0.0
>
>
> I did a minimal install of CentOS 7, installed TO, when I run postinstall I 
> get:
> # ./postinstall Can't locate Term/ReadPassword.pm in @INC (@INC contains: 
> /opt/traffic_ops/install/lib /opt/traffic_ops/install/lib/perl5 
> /opt/traffic_ops/app/local/lib/perl5 /opt/traffic_ops/app/lib 
> /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl 
> /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at 
> /opt/traffic_ops/install/lib/InstallUtils.pm line 37. BEGIN 
> failed--compilation aborted at /opt/traffic_ops/install/lib/InstallUtils.pm 
> line 37.
> This perl module isn't available via yum.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-234) TO postinstall error moving coverage-zone.json

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-234:
--

Assignee: Dan Kirkwood

> TO postinstall error moving coverage-zone.json
> --
>
> Key: TC-234
> URL: https://issues.apache.org/jira/browse/TC-234
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
> Fix For: 2.0.0
>
>
> This is a regression from 1.8.x -- if answering "no" to "Download MaxMind 
> data", I get this message from postinstall:
> Not downloading Maxmind data
> Copying coverage zone file to public dir
> /bin/mv: cannot stat ‘/opt/traffic_ops/app/public/coverage-zone.json’: No 
> such file or directory



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-154) Adding cronjob to automatically clean iso generation

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-154:
--

Assignee: Dewayne Richardson

> Adding cronjob to automatically clean iso generation
> 
>
> Key: TC-154
> URL: https://issues.apache.org/jira/browse/TC-154
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Affects Versions: 2.0.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>Priority: Minor
> Fix For: 2.0.0
>
>
> Need a cronjob to be added to automatically clean ISOs older than 7 days



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-160) ip6gateway should not be required

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-160:
--

Assignee: Dan Kirkwood

> ip6gateway should not be required
> -
>
> Key: TC-160
> URL: https://issues.apache.org/jira/browse/TC-160
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Affects Versions: 2.0.0
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
> Fix For: 2.1.0
>
>
> when adding a new server with an ip6 address,  Traffic Ops (both GUI and API) 
> require ip6 gateway within the same network as the address.
> But,  ip6 gateways commonly use a link-local address (e.g. in the fe80:: 
> range).   The check when adding a new server is not valid in this case.
> Traffic Ops should either not require the gateway,  loosen the restriction on 
> the gateway address,  or eliminate the gateway from the server completely.
> A sample error shown below:
> ```2000:2000:2000::1 and fe80::99 are not in same network```



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-102) API changes to reflect true datatypes

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-102:
--

Assignee: Jeremy Mitchell

> API changes to reflect true datatypes
> -
>
> Key: TC-102
> URL: https://issues.apache.org/jira/browse/TC-102
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.0.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>  Labels: postgres
> Fix For: 2.0.0
>
>
> With the move from MySQL to Postgres, the API will reflect the true data 
> types of each value as represented in the database. For example, the Postgres 
> version of the TO database now has boolean columns (rather than using 
> smallint). These values should be represented in the API as booleans 
> (true|false) as opposed to "0"|"1" as before.
> Also, in the old MySQL TO, ints or numbers were represented as "age":"23" in 
> the API. That should change to "age":23
> These are the datatypes available in json and they should be taken advantage 
> of when possible:
> Boolean:  true|false
> String: double-quoted Unicode with backslash escaping
> Number: double- precision floating-point format
> Array: an ordered sequence of values
> Object: an unordered collection of key:value pairs
> Null
> I'm creating this issue as a catch-all for any changes required to reflect 
> the true data types in the api.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-81) Add additional filters to collection apis

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-81:
-

Assignee: Jeremy Mitchell

> Add additional filters to collection apis
> -
>
> Key: TC-81
> URL: https://issues.apache.org/jira/browse/TC-81
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
> Fix For: 1.9.0
>
>
> Add the ability to filter the following collections as follows:
> /api/deliveryservices/:id/servers <-- retrieve all edge servers assigned to a 
> ds
> /api/servers/:id/deliveryservices <-- retrieve all ds's assigend to a server
> /api/parameters/:id/profiles <-- retrieve all profiles assigned to a parameter
> /api/users/:id/deliveryservices <-- retrieve all ds's assigned to a user
> /api/deliveryservices?cdn=x <-- to retrieve a cdn's ds's
> /api/regions?division=x <-- to retrieve a division's regions
> /api/servers?physLocation=x <-- to retrieve a phys location's servers
> /api/cachegroups?type=x <-- to retrieve cachegroups by type
> /api/deliveryservices?type=x <-- to retrieve deliveryservices by type
> The api already provides the ability to:
> - retrieve a cachegroup's asns
> - retrieve a cachegroup's parameters
> - retrieve a cachegroup's servers
> - retrieve a cdn's servers
> - retrieve a profile's parameters
> - retrieve a profile's servers
> - retrieve a region's phys locations
> By adding these additional filters, it provides the ability to navigate the 
> relationships in the database (i.e. provides drill-down capabilities)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-80) Add api/version/cachegroups/:id/parameters endpoint

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-80:
-

Assignee: Jeremy Mitchell

> Add api/version/cachegroups/:id/parameters endpoint
> ---
>
> Key: TC-80
> URL: https://issues.apache.org/jira/browse/TC-80
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
> Fix For: 1.9.0
>
>
> Provide the ability to fetch cachegroup parameters through the api such as
> api/version/cachegroups/:id/parameters
> Also, while you're in there, provide the ability to fetch cachegroup asns 
> through the api such as:
> api/version/asns?cachegroup=x
> and filter phys locations by region like:
> api/version/physLocations?region=x



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-47) Test Cases for Traffic Ops in the psql-rebase branch are broken

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-47:
-

Assignee: Dewayne Richardson

> Test Cases for Traffic Ops in the psql-rebase branch are broken
> ---
>
> Key: TC-47
> URL: https://issues.apache.org/jira/browse/TC-47
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-39) LICENSE file is incomplete

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-39:
-

Assignee: Dan Kirkwood

> LICENSE file is incomplete
> --
>
> Key: TC-39
> URL: https://issues.apache.org/jira/browse/TC-39
> Project: Traffic Control
>  Issue Type: Bug
>Reporter: Eric Friedrich
>Assignee: Dan Kirkwood
>Priority: Minor
> Fix For: 1.8.0
>
>
> Our LICENSE file only includes Apache License, but not the licenses of all 
> our bundled dependencies. 
> From 
> https://incubator.apache.org/guides/releasemanagement.html#best-practice-license:
> bq. "All the licenses on all the files to be included within a package should 
> be included in the LICENSE document. This LICENSE (courtesy of Apache HTTPD) 
> is a good example. The Apache License is at the top of the LICENSE document. 
> After that, the license for each non-Apache licensed component is included, 
> along with a clear explanation of which files that license applies to."



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-35) Add trafficserver diff for trafficserver-5.3.2.ee14bbe

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-35:
-

Assignee: John Rushford

> Add trafficserver diff for trafficserver-5.3.2.ee14bbe
> --
>
> Key: TC-35
> URL: https://issues.apache.org/jira/browse/TC-35
> Project: Traffic Control
>  Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: John Rushford
>Assignee: John Rushford
>Priority: Trivial
> Fix For: 1.7.0
>
>
> Add the diff file for trafficserver-5.3.2.ee14bbe



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TC-411) Traffic Router Log Aggregation

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-411:
--

 Summary: Traffic Router Log Aggregation
 Key: TC-411
 URL: https://issues.apache.org/jira/browse/TC-411
 Project: Traffic Control
  Issue Type: New Feature
  Components: Traffic Analytics
Reporter: Ryan Durfey


Aggregate Traffic Router logs into one minute intervals 

Breaking down bytes, requests,  time to serve (ttms), and users into various 
buckets allows for rapid charting for analytics, reporting, and monitoring
Sum of requests, count chi (user IPs)
by Server
by Service
by CDN
by Type (HTTP Redirect or DNS Nameserver)
by Service (CDN service)
by Host (Traffic Router)
by Destination (Cache Group)
by Request Type (A or )
Other?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-392) Traffic Server Log aggregation in 1 min intervals for delivery service charting

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-392:
---
 Labels: log_aggregation logs  (was: chart influx log_aggregation logs)
Description: 
Breaking down bytes, requests,  time to serve (ttms), and users into various 
buckets allows for rapid charting for analytics, reporting, and monitoring
Sum of bytes, sum of requests, sum ttms(time to serve milliseconds), count chi 
(user IPs)
by CDN
by Service (CDN service)
by Host (server)
by Cache Group (site or geo)
by IPtype (IPv4 or IPv6)
by pssc (http return code)
by crc (cache response code)
by minute

  was:
Today, log aggregation is performed in a separate commercial system.  This 
should be done in an open source system and aggregated into a an open source 
time series database.

Once traffic logs is complete, we should begin aggregating logs on 1 min 
intervals for charting and graphing in a time series database like influx.db.
Key Fields to aggregate:
bandwidith, tps, http codes, crc, tier, etc...  

Start with what exists in the portal today.  We would also like to expand on 
this based on our monitoring experience.

Component/s: (was: Traffic Ops API)
 (was: Traffic Portal)
Summary: Traffic Server Log aggregation in 1 min intervals for delivery 
service charting  (was: Log aggregation in 1 min intervals for delivery service 
charting)

> Traffic Server Log aggregation in 1 min intervals for delivery service 
> charting
> ---
>
> Key: TC-392
> URL: https://issues.apache.org/jira/browse/TC-392
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Analytics
>Reporter: Ryan Durfey
>  Labels: log_aggregation, logs
>
> Breaking down bytes, requests,  time to serve (ttms), and users into various 
> buckets allows for rapid charting for analytics, reporting, and monitoring
> Sum of bytes, sum of requests, sum ttms(time to serve milliseconds), count 
> chi (user IPs)
> by CDN
> by Service (CDN service)
> by Host (server)
> by Cache Group (site or geo)
> by IPtype (IPv4 or IPv6)
> by pssc (http return code)
> by crc (cache response code)
> by minute



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TC-410) Traffic Ops Configuration Change Logs into Traffic Analytics system

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-410:
--

 Summary: Traffic Ops Configuration Change Logs into Traffic 
Analytics system
 Key: TC-410
 URL: https://issues.apache.org/jira/browse/TC-410
 Project: Traffic Control
  Issue Type: New Feature
  Components: Traffic Analytics
Reporter: Ryan Durfey


Push traffic ops configuration change logs into the Traffic Analytics system



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (TC-364) create ability to assign/remove delivery services to/from a user

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey resolved TC-364.

Resolution: Fixed
  Assignee: Jeremy Mitchell

> create ability to assign/remove delivery services to/from a user
> 
>
> Key: TC-364
> URL: https://issues.apache.org/jira/browse/TC-364
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>  Labels: assignment, delivery_service, user
>
> Create api endpoints to:
> - assign 1 or more ds's to a user
> - remove a ds from a user
> - retrieve ds's not currently assigned to user
> these functions should be limited to the ops role or higher.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-275) Export/Import delivery service

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-275:
--

Assignee: Dylan Volz

> Export/Import delivery service
> --
>
> Key: TC-275
> URL: https://issues.apache.org/jira/browse/TC-275
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Matt Mills
>Assignee: Dylan Volz
>Priority: Minor
>  Labels: configuration, testing
>
> Feature Request, low priority.
> I'd like to be able to export/import delivery services so I can take an 
> entire delivery service from production into an alternate environment for 
> testing. It'd also need to be able to prompt you at import time for the 
> config components that don't line up between environments (if your profile 
> doesnt exist, select a new one, select new servers/cache groups for the DS to 
> be on).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-386) Docker Image for Traffic Ops Update

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-386:
---
Summary: Docker Image for Traffic Ops Update  (was: Update traffic ops 
docker image)

> Docker Image for Traffic Ops Update
> ---
>
> Key: TC-386
> URL: https://issues.apache.org/jira/browse/TC-386
> Project: Traffic Control
>  Issue Type: Task
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dylan Volz
>Assignee: Dylan Volz
>Priority: Minor
>  Labels: build, docker
>
> The traffic ops install process has changed and the docker image requires 
> updating to be usable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-387) Max IP Address in DNS Answer - Make Dynamic based on Traffic Load

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-387:
---
Description: 
Currently when we build a DNS routed service there is a parameter assigned 
called maximum IP address which determines how many cache IPs in each cache 
group should be handed out to the DNS system for the client.  This determines 
the number of caches across which content is assigned. For small services we 
typically assign 1-2 caches for larger services we assign 3-5 caches.  

This is currently done manually and if a service grows rapidly they could be 
handling a large volume of traffic and only have one cache in each group 
assigned.

I would like to consider some type of feedback loop which gages the popularity 
of a service and dynamically adjusts the number of cache IPs handed out. 

We should also consider splitting up this behavior of tying DNS address hand 
out to the number of caches across which we hash content.   These should be 
separate configuration and only the number of caches to hash across needs to be 
dynamic.

  was:
Currently when we build a DNS routed service there is a parameter assigned 
called maximum IP address which determines how many cache IPs in each cache 
group should be handed out to the DNS system for the client.  This determines 
the number of caches across which content is assigned. For small services we 
typically assign 1-2 caches for larger services we assign 3-5 caches.  

This is currently done manually and if a service grows rapidly they could be 
handling a large volume of traffic and only have one cache in each group 
assigned.

I would like to consider some type of feedback loop which gages the popularity 
of a service and dynamically adjusts the number of cache IPs handed out. 

Summary: Max IP Address in DNS Answer - Make Dynamic based on Traffic 
Load  (was: Dynamic assignment of max-ip address in DNS answer parameter for 
DNS routed services)

> Max IP Address in DNS Answer - Make Dynamic based on Traffic Load
> -
>
> Key: TC-387
> URL: https://issues.apache.org/jira/browse/TC-387
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Router
>Reporter: Ryan Durfey
>Assignee: Jeff Elsloo
>  Labels: dns, routing
>
> Currently when we build a DNS routed service there is a parameter assigned 
> called maximum IP address which determines how many cache IPs in each cache 
> group should be handed out to the DNS system for the client.  This determines 
> the number of caches across which content is assigned. For small services we 
> typically assign 1-2 caches for larger services we assign 3-5 caches.  
> This is currently done manually and if a service grows rapidly they could be 
> handling a large volume of traffic and only have one cache in each group 
> assigned.
> I would like to consider some type of feedback loop which gages the 
> popularity of a service and dynamically adjusts the number of cache IPs 
> handed out. 
> We should also consider splitting up this behavior of tying DNS address hand 
> out to the number of caches across which we hash content.   These should be 
> separate configuration and only the number of caches to hash across needs to 
> be dynamic.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-388) Max IP Address in DNS Answer - Default Behavior Change

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-388:
---
Summary: Max IP Address in DNS Answer - Default Behavior Change  (was: Max 
IP Address in DNS Answer Behavior Change)

> Max IP Address in DNS Answer - Default Behavior Change
> --
>
> Key: TC-388
> URL: https://issues.apache.org/jira/browse/TC-388
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Router
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>  Labels: dns, routing
>
> The current default configuration for "Maximum IP addresses in DNS answer" is 
> zero  which causes the Traffic Router to return all IP addresses in  a cache 
> group to the DNS system for a client.  As cache groups grow beyond ~20 caches 
> the responses get too long for some networks and clients to handle. We have 
> seen specific instances where this breaks on the Verizon network.
> I suggest we make the default some lower but reasonable number that works in 
> most cases like "3".  This is a better default that would work for most small 
> to mid size services.  Savvy users who know to change this would be 
> unaffected. But this could save lots of errors for inexperienced users.
> I would also suggest that we consider an upper bound limitation like "10" for 
> at least a warning to users trying to configure a hire number.  If you have 
> to assign more than this then we should consider decoupling the number of IPs 
> returned from the number of servers that content is hashed across.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-393) Traffic Ops API Gateway

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-393:
--

Assignee: Nir Sopher

> Traffic Ops API Gateway
> ---
>
> Key: TC-393
> URL: https://issues.apache.org/jira/browse/TC-393
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>Assignee: Nir Sopher
>Priority: Critical
>
> Build API gateway for Traffic Ops
> See: https://cwiki.apache.org/confluence/display/TC/API+Gateway
> See: 
> https://lists.apache.org/thread.html/e7aa72c73177a25a6a834ebca268c9ac973f547ce77d5331e7f84ee0@%3Cdev.trafficcontrol.apache.org%3E
> See https://github.com/apache/incubator-trafficcontrol/pull/567



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-82) Eliminate duplicate implementations of deliveryservice, cachegroup and server api endpoints

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-82:
-

Assignee: (was: Ryan Durfey)

> Eliminate duplicate implementations of deliveryservice, cachegroup and server 
> api endpoints
> ---
>
> Key: TC-82
> URL: https://issues.apache.org/jira/browse/TC-82
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: api_endpoints
>
> The following endpoints are duplicates and need to be reconciled:
> Delivery Services:
> GET /api/$version/deliveryservices
> GET /api/$version/deliveryservices/list <-- remove
> GET /api/$version/deliveryservices/:id
> GET /api/$version/deliveryservices/:id/get <-- remove
> POST /api/$version/deliveryservices
> POST /api/$version/deliveryservices/create <-- remove
> PUT /api/$version/deliveryservices/:id
> PUT /api/$version/deliveryservices/:id/update <-- remove
> Cache Groups:
> GET /api/$version/cachegroups
> GET /api/$version/cachegroups/list <-- remove
> POST /api/$version/cachegroups
> POST /api/$version/cachegroups/create <-- remove
> PUT /api/$version/cachegroups/:id
> PUT /api/$version/cachegroups/:id/update <-- remove
> DELETE /api/$version/cachegroups/:id
> DELETE /api/$version/cachegroups/:id/delete <-- remove
> Servers:
> POST /api/$version/servers
> POST /api/$version/servers/create <-- remove
> PUT /api/$version/servers/:id
> PUT /api/$version/servers/:id/update <-- remove



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-82) Eliminate duplicate implementations of deliveryservice, cachegroup and server api endpoints

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-82:
-

Assignee: Ryan Durfey  (was: Jeremy Mitchell)

> Eliminate duplicate implementations of deliveryservice, cachegroup and server 
> api endpoints
> ---
>
> Key: TC-82
> URL: https://issues.apache.org/jira/browse/TC-82
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Ryan Durfey
>Priority: Minor
>  Labels: api_endpoints
>
> The following endpoints are duplicates and need to be reconciled:
> Delivery Services:
> GET /api/$version/deliveryservices
> GET /api/$version/deliveryservices/list <-- remove
> GET /api/$version/deliveryservices/:id
> GET /api/$version/deliveryservices/:id/get <-- remove
> POST /api/$version/deliveryservices
> POST /api/$version/deliveryservices/create <-- remove
> PUT /api/$version/deliveryservices/:id
> PUT /api/$version/deliveryservices/:id/update <-- remove
> Cache Groups:
> GET /api/$version/cachegroups
> GET /api/$version/cachegroups/list <-- remove
> POST /api/$version/cachegroups
> POST /api/$version/cachegroups/create <-- remove
> PUT /api/$version/cachegroups/:id
> PUT /api/$version/cachegroups/:id/update <-- remove
> DELETE /api/$version/cachegroups/:id
> DELETE /api/$version/cachegroups/:id/delete <-- remove
> Servers:
> POST /api/$version/servers
> POST /api/$version/servers/create <-- remove
> PUT /api/$version/servers/:id
> PUT /api/$version/servers/:id/update <-- remove



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TC-394) Scale Components to Handle > 2,000 delivery services

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-394:
--

 Summary: Scale Components to Handle > 2,000 delivery services
 Key: TC-394
 URL: https://issues.apache.org/jira/browse/TC-394
 Project: Traffic Control
  Issue Type: Improvement
  Components: Traffic Ops, Traffic Router
Reporter: Ryan Durfey


We have several resellers that are interested in using our CDN.  These 
companies have 1,000+ small delivery services spread across ~250 sub-tenants.  
We need to ensure that core components will scale to handle this many services 
without impacting existing customers.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-393) Traffic Ops API Gateway

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-393:
--

Assignee: (was: Ryan Durfey)

> Traffic Ops API Gateway
> ---
>
> Key: TC-393
> URL: https://issues.apache.org/jira/browse/TC-393
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>Priority: Critical
>
> Build API gateway for Traffic Ops
> See: https://cwiki.apache.org/confluence/display/TC/API+Gateway
> See: 
> https://lists.apache.org/thread.html/e7aa72c73177a25a6a834ebca268c9ac973f547ce77d5331e7f84ee0@%3Cdev.trafficcontrol.apache.org%3E
> See https://github.com/apache/incubator-trafficcontrol/pull/567



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-393) Traffic Ops API Gateway

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-393:
---
Description: 
Build API gateway for Traffic Ops

See: https://cwiki.apache.org/confluence/display/TC/API+Gateway
See: 
https://lists.apache.org/thread.html/e7aa72c73177a25a6a834ebca268c9ac973f547ce77d5331e7f84ee0@%3Cdev.trafficcontrol.apache.org%3E
See https://github.com/apache/incubator-trafficcontrol/pull/567

  was:
Build API gateway for Traffic Ops

See: https://cwiki.apache.org/confluence/display/TC/API+Gateway
See: 
https://lists.apache.org/thread.html/e7aa72c73177a25a6a834ebca268c9ac973f547ce77d5331e7f84ee0@%3Cdev.trafficcontrol.apache.org%3E


> Traffic Ops API Gateway
> ---
>
> Key: TC-393
> URL: https://issues.apache.org/jira/browse/TC-393
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>Assignee: Ryan Durfey
>Priority: Critical
>
> Build API gateway for Traffic Ops
> See: https://cwiki.apache.org/confluence/display/TC/API+Gateway
> See: 
> https://lists.apache.org/thread.html/e7aa72c73177a25a6a834ebca268c9ac973f547ce77d5331e7f84ee0@%3Cdev.trafficcontrol.apache.org%3E
> See https://github.com/apache/incubator-trafficcontrol/pull/567



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-393) Traffic Ops API Gateway

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-393:
--

Assignee: Ryan Durfey

> Traffic Ops API Gateway
> ---
>
> Key: TC-393
> URL: https://issues.apache.org/jira/browse/TC-393
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>Assignee: Ryan Durfey
>Priority: Critical
>
> Build API gateway for Traffic Ops
> See: https://cwiki.apache.org/confluence/display/TC/API+Gateway
> See: 
> https://lists.apache.org/thread.html/e7aa72c73177a25a6a834ebca268c9ac973f547ce77d5331e7f84ee0@%3Cdev.trafficcontrol.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TC-393) Traffic Ops API Gateway

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-393:
--

 Summary: Traffic Ops API Gateway
 Key: TC-393
 URL: https://issues.apache.org/jira/browse/TC-393
 Project: Traffic Control
  Issue Type: New Feature
  Components: Traffic Ops API
Affects Versions: 2.1.0
Reporter: Ryan Durfey
Priority: Critical


Build API gateway for Traffic Ops

See: https://cwiki.apache.org/confluence/display/TC/API+Gateway
See: 
https://lists.apache.org/thread.html/e7aa72c73177a25a6a834ebca268c9ac973f547ce77d5331e7f84ee0@%3Cdev.trafficcontrol.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-392) Log aggregation in 1 min intervals for delivery service charting

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-392:
---
Component/s: (was: Traffic Logs)
 Traffic Analytics

> Log aggregation in 1 min intervals for delivery service charting
> 
>
> Key: TC-392
> URL: https://issues.apache.org/jira/browse/TC-392
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Analytics, Traffic Ops API, Traffic Portal
>Reporter: Ryan Durfey
>  Labels: chart, influx, log_aggregation, logs
>
> Today, log aggregation is performed in a separate commercial system.  This 
> should be done in an open source system and aggregated into a an open source 
> time series database.
> Once traffic logs is complete, we should begin aggregating logs on 1 min 
> intervals for charting and graphing in a time series database like influx.db.
> Key Fields to aggregate:
> bandwidith, tps, http codes, crc, tier, etc...  
> Start with what exists in the portal today.  We would also like to expand on 
> this based on our monitoring experience.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-392) Log aggregation in 1 min intervals for delivery service charting

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-392:
---
Issue Type: New Feature  (was: Bug)

> Log aggregation in 1 min intervals for delivery service charting
> 
>
> Key: TC-392
> URL: https://issues.apache.org/jira/browse/TC-392
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Analytics, Traffic Ops API, Traffic Portal
>Reporter: Ryan Durfey
>  Labels: chart, influx, log_aggregation, logs
>
> Today, log aggregation is performed in a separate commercial system.  This 
> should be done in an open source system and aggregated into a an open source 
> time series database.
> Once traffic logs is complete, we should begin aggregating logs on 1 min 
> intervals for charting and graphing in a time series database like influx.db.
> Key Fields to aggregate:
> bandwidith, tps, http codes, crc, tier, etc...  
> Start with what exists in the portal today.  We would also like to expand on 
> this based on our monitoring experience.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-368) api/1.2/deliveryservices/:id/routing.json hangs when Traffic Router is unreachable

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-368:
---
 Labels: api_deliveryservices routing  (was: routing)
Summary: api/1.2/deliveryservices/:id/routing.json hangs when Traffic 
Router is unreachable  (was: /api/1.2/deliveryservices/:id/routing.json hangs 
when Traffic Router is unreachable)

> api/1.2/deliveryservices/:id/routing.json hangs when Traffic Router is 
> unreachable
> --
>
> Key: TC-368
> URL: https://issues.apache.org/jira/browse/TC-368
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 1.8.0
>Reporter: Steve Malenfant
>  Labels: api_deliveryservices, routing
>
> I was testing this API "/api/1.2/deliveryservices/:id/routing.json" and found 
> that it would hang and the perl worker had to be killled. This caused 500 
> Errors back from TO API.
> The root cause is Traffic Router not responding to API Port. 
> We should not poll Traffic Router that are status=OFFLINE and there should be 
> some sort of timeouts in place to make sure it doesn't take more than x 
> seconds to return information from API
> There is some comments in the code that seems to indication prior issues.
> `# TODO: what happens when the request to CCR times out?`



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-130) Service Configuration Streamlining and Sequencing

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-130:
---
Labels: configuration state_machine  (was: configruation state_machine)

> Service Configuration Streamlining and Sequencing
> -
>
> Key: TC-130
> URL: https://issues.apache.org/jira/browse/TC-130
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API, Traffic Router
>Reporter: Nir Sopher
>  Labels: configuration, state_machine
>
> Hi,
> In order to further improve the simplicity and robustness of the control path 
> for provisioning infrastructure and delivery services, we are currently 
> considering ways to streamline management and operations.
> Currently, when applying changes in traffic-control that require the 
> synchronization between the traffic-router and traffic-servers, the user 
> should be conscious to do so in a certain order. Otherwise, "black holes" may 
> be created. Furthermore, in some of the scenarios the user have to wait and 
> verify that the configuration reached all traffic server before he may apply 
> it to the traffic-router. 
> The main use-cases we would like to address at this point are:
> * Assign servers to a Delivery-Service. 
> For this operation, the configuration must first be applied to the added 
> traffic servers, propagate, and only then applied to the traffic-router.
> * Remove servers assignment to a Delivery-Service. 
> For this operation, the configuration must first be applied to the 
> traffic-router, and only then to the traffic-servers.
> * Add a new delivery service.
> This is practically a private case of servers assignment to a 
> delivery-service.
> * Delete a delivery service.
> This is practically a private case of servers assignment removal from a 
> delivery-service.
> * Update settings that must be applied together on the traffic servers and 
> the router. 
> We would like to simplify the procedure, allowing the deployment of new 
> configuration in a single operation, instead of doing it step by step. 
> One solution can be based on the insight that deploying such configuration 
> changes may be done by initially updating the traffic server with added 
> functionality (e.g remap-rule), then updating the router, and lastly, 
> removing old functionality from the traffic servers. Such a solution can be 
> orchestrated by traffic-ops, probably without complicating other components.
> Other solutions may provide more flexibility, but would probably involve 
> adding complexity to other components such as traffic-router. 
> An example to such a solution, already under discussion in a mail tread (10x 
> Eric:) may be based on the concept of a delivery-service configuration 
> "generation" which would be an ordinal identifier for the a delivery service 
> configuration. A "generation" changes whenever the remap rule changes or the 
> consistent hash mapping of content to server changes (e.g. due to additional 
> server assignment).
> In such a solution, each traffic-server may hold a single generation for each 
> delivery service configuration, while traffic-router may hold a history of 
> generations and know which server holds which configuration generation.
> This approach introduces a considerable flexibility. It allows configurations 
> to be set one after the other with no need to wait between them.
> On the other hand, complicated algorithms for solving the issue may impose 
> more risk to the network when applied, comparing to a simple "traffic-ops" 
> orchestrated solution.
> Both approaches fit well with TC-129: Create TO API endpoint to queue all 
> servers for a delivery service
> I'm not sure what is preferable from an operator point of view. I'm also not 
> familiar with TC 3.0 "Config State Machine" solution to validate he different 
> approaches against.
> Nir



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-157) Failed to restart tomcat in Traffic Router when failed to get SSL keys

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-157:
---
Attachment: text.html

Zhilin,

Thanks for the feedback on these. I am working on getting additional committers 
involved.

Ryan DurfeyM | 303-524-5099
CDN Support (24x7): 866-405-2993 or 
cdn_supp...@comcast.com


From: "Zhilin Huang (JIRA)" 
Date: Thursday, June 15, 2017 at 1:18 AM
To: Ryan Durfey 
Subject: [jira] [Commented] (TC-157) Failed to restart tomcat in Traffic Router 
when failed to get SSL keys


[ 
https://issues.apache.org/jira/browse/TC-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050004#comment-16050004
 ]

Zhilin Huang commented on TC-157:
-

I don't think so, the PR is still open.

Failed to restart tomcat in Traffic Router when failed to get SSL keys
--

 Key: TC-157
 URL: https://issues.apache.org/jira/browse/TC-157
 Project: Traffic Control
  Issue Type: Bug
  Components: Traffic Router
Affects Versions: 1.7.0
Reporter: Zhilin Huang
Assignee: Zhilin Huang
  Labels: ssl, tomcat

Stopping tomcat failed with the following log:
WARN  2017-02-17T09:00:05.939 [main] 
com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesPublisher
 - Detected destroy setting running to false
INFO  2017-02-17T09:00:05.943 [pool-2-thread-1] 
com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesClient - 
Interrupted while pausing for check of traffic ops config
INFO  2017-02-17T09:00:05.943 [pool-2-thread-1] 
com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - POSTing: 
https://192.168.122.181/api/1.1/user/login; timeout is 15000
INFO  2017-02-17T09:00:06.005 [pool-2-thread-1] 
com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: 
https://192.168.122.181/api/1.2/cdns/name/kabletown_cdn/sslkeys.jso
n; timeout is 15000
WARN  2017-02-17T09:00:06.040 [pool-2-thread-1] 
com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - Failed Http 
Request to https://192.168.122.181/api/1.2/cdns/name/kabletown_
cdn/sslkeys.json Status 400



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)




> Failed to restart tomcat in Traffic Router when failed to get SSL keys
> --
>
> Key: TC-157
> URL: https://issues.apache.org/jira/browse/TC-157
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 1.7.0
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>  Labels: ssl, tomcat
> Attachments: text.html
>
>
> Stopping tomcat failed with the following log:
> WARN  2017-02-17T09:00:05.939 [main] 
> com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesPublisher
>  - Detected destroy setting running to false
> INFO  2017-02-17T09:00:05.943 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesClient 
> - Interrupted while pausing for check of traffic ops config
> INFO  2017-02-17T09:00:05.943 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - POSTing: 
> https://192.168.122.181/api/1.1/user/login; timeout is 15000
> INFO  2017-02-17T09:00:06.005 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: 
> https://192.168.122.181/api/1.2/cdns/name/kabletown_cdn/sslkeys.jso
> n; timeout is 15000
> WARN  2017-02-17T09:00:06.040 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - Failed 
> Http Request to https://192.168.122.181/api/1.2/cdns/name/kabletown_
> cdn/sslkeys.json Status 400



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-5) LSBify all init scripts

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-5:
-
 Labels: build lsb  (was: )
Component/s: Traffic Ops

> LSBify all init scripts
> ---
>
> Key: TC-5
> URL: https://issues.apache.org/jira/browse/TC-5
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Mark Torluemke
>Priority: Minor
>  Labels: build, lsb
>
> CentOS 7.x kicks out warnings like this:
> [68482.268987] systemd-sysv-generator[22518]: 
> [/etc/rc.d/init.d/traffic_ops:24] PID file not absolute. Ignoring.
> thanks @elsloo!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-26) Prepare Docker Environment for Traffic Portal

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-26:
--
Labels: build docker  (was: )

> Prepare Docker Environment for Traffic Portal
> -
>
> Key: TC-26
> URL: https://issues.apache.org/jira/browse/TC-26
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Portal
>Affects Versions: 1.8.0
> Environment: Dev
>Reporter: Burak SARP
>  Labels: build, docker
> Fix For: 2.1.0
>
>
> Prepare Docker Environment for Traffic Portal



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-29) Traffic Router TPS for HTTPS requests diminishes when reloading certificates

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-29:
--
Labels: performance ssl  (was: )

> Traffic Router TPS for HTTPS requests diminishes when reloading certificates
> 
>
> Key: TC-29
> URL: https://issues.apache.org/jira/browse/TC-29
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Reporter: David Neuman
>  Labels: performance, ssl
>
> When Traffic Router reloads SSL certificates while processing HTTPS 
> transactions, the TPS drops significantly. 
> Example Log output during the drop in TPS: 
> INFO  2016-11-07T14:05:23.363 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: 
> https://to.kabletown.net/api/1.2/cdns/name/test-xc
> r/sslkeys.json; timeout is 15000
> INFO  2016-11-07T14:05:23.500 [New I/O worker #8] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.ConfigHandler - 
> Entered processConfig
> INFO  2016-11-07T14:05:23.500 [New I/O worker #8] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.ConfigHandler - 
> Exiting processConfig: No json data to process
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-02 domain ds-02.cdn.kabletown.net.net
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-01 domain ds-01.cdn.kabletown.net.net
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-05 domain ds-05.cdn.kabletown.net.net
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-04 domain ds-04.cdn.kabletown.net.net
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-03 domain ds-03.cdn.kabletown.net.net
> INFO  2016-11-07T14:05:43.399 [pool-17-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: 
> https://to.kabletown.net/api/1.1/cdns/name/test-xcr/dnsseckeys.json; timeout 
> is 3
> INFO  2016-11-07T14:06:23.339 [pool-5-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.monitor.TrafficMonitorWatcher
>  - Loading properties from /opt/traffic_router/conf/traffic_monitor.properties



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-44) TR fd leak observed when new HTTPS DS is added without certificate

[Ryan Durfey (JIRA)]

[ 
https://issues.apache.org/jira/browse/TC-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049640#comment-16049640
 ] 

Ryan Durfey commented on TC-44:
---

Is this resolved?

> TR fd leak observed when new HTTPS DS is added without certificate
> --
>
> Key: TC-44
> URL: https://issues.apache.org/jira/browse/TC-44
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 1.7.0
>Reporter: John Shen
>Assignee: John Shen
> Fix For: 2.1.0
>
>
> In TC 1.7, when a new HTTPS DS (HTTP 302 routing) is added without 
> certificate, there will be fd leak observed on TR. The connections to TM stay 
> in CLOSE-WAIT, which begins to show ~20mins after a new DS without cert/key 
> is added.
> And CrState appears to be blocked in ~20mins as well, i.e. no request from TR 
> to TM to fetch CrState.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-50) Mitigate json.org dependency

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-50:
--
Labels: dependancy json.org  (was: )

> Mitigate json.org dependency
> 
>
> Key: TC-50
> URL: https://issues.apache.org/jira/browse/TC-50
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Router
>Affects Versions: 1.9.0
>Reporter: Mark Torluemke
>  Labels: dependancy, json.org
>
> Per this email:
> {noformat}
> From: Ted Dunning 
> Reply-To: "gene...@incubator.apache.org" 
> Date: Wednesday, November 23, 2016 at 6:10 PM
> To: "gene...@incubator.apache.org" 
> Subject: Fwd: JSON License and Apache Projects
> The VP Legal for Apache has determined that the JSON processing library
> from json.org  is not usable as a
> dependency by Apache projects. This is because the license includes a line
> that places a field of use condition on downstream users in a way that is
> not compatible with Apache's license.
> This decision is, unfortunately, a change from the previous situation.
> While the current decision is correct, it would have been nice if we had
> had this decision originally.
> As such, some existing projects may be impacted because they assumed that
> the json.org dependency was OK to use.
> Incubator projects that are currently using the json.org library have
> several courses of action:
> 1) just drop it. Some projects like Storm have demos that use twitter4j
> which incorporates the problematic code. These demos aren't core and could
> just be dropped for a time.
> 2) help dependencies move away from problem code. I have sent a pull
> request to twitter4 j, for
> example, that eliminates the problem. If they accept the pull, then all
> would be good for the projects that use twitter4j (and thus json.org)
> 3) replace the json.org artifact with a compatible one that is open source.
> I have created and published an artifact based on clean-room Android code
>  that replicates the most important
> parts of the json.org code. This code is compatible, but lacks some
> coverage. It also could lead to jar hell if used unjudiciously because it
> uses the org.json package. Shading and exclusion in a pom might help. Or
> not. Go with caution here.
> 4) switch to safer alternatives such as Jackson. This requires code
> changes, but is probably a good thing to do. This option is the one that is
> best in the long-term but is also the most expensive.
> -- Forwarded message --
> From: Jim Jagielski 
> Date: Wed, Nov 23, 2016 at 6:10 AM
> Subject: JSON License and Apache Projects
> To: ASF Board 
> (forwarded from legal-discuss@)
> As some of you may know, recently the JSON License has been
> moved to Category X (https://www.apache.org/legal/resolved#category-x).
> I understand that this has impacted some projects, especially
> those in the midst of doing a release. I also understand that
> up until now, really, there has been no real "outcry" over our
> usage of it, especially from end-users and other consumers of
> our projects which use it.
> As compelling as that is, the fact is that the JSON license
> itself is not OSI approved and is therefore not, by definition,
> an "Open Source license" and, as such, cannot be considered as
> one which is acceptable as related to categories.
> Therefore, w/ my VP Legal hat on, I am making the following
> statements:
> o No new project, sub-project or codebase, which has not
>used JSON licensed jars (or similar), are allowed to use
>them. In other words, if you haven't been using them, you
>aren't allowed to start. It is Cat-X.
> o If you have been using it, and have done so in a *release*,
>AND there has been NO pushback from your community/eco-system,
>you have a temporary exclusion from the Cat-X classification thru
>April 30, 2017. At that point in time, ANY and ALL usage
>of these JSON licensed artifacts are DISALLOWED. You must
>either find a suitably licensed replacement, or do without.
>There will be NO exceptions.
> o Any situation not covered by the above is an implicit
>DISALLOWAL of usage.
> Also please note that in the 2nd situation (where a temporary
> exclusion has been granted), you MUST ensure that NOTICE explicitly
> notifies the end-user that a JSON licensed artifact exists. They
> may not be aware of it up to now, and that MUST be addressed.
> If there are any questions, please ask on the legal-discuss@a.o
> list.
> --
> Jim Jagielski
> VP Legal Affairs
> {noformat}
> I see it in the pom.xml: 
> 

[jira] [Commented] (TC-29) Traffic Router TPS for HTTPS requests diminishes when reloading certificates

[Ryan Durfey (JIRA)]

[ 
https://issues.apache.org/jira/browse/TC-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049641#comment-16049641
 ] 

Ryan Durfey commented on TC-29:
---

Is this resolved?

> Traffic Router TPS for HTTPS requests diminishes when reloading certificates
> 
>
> Key: TC-29
> URL: https://issues.apache.org/jira/browse/TC-29
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Reporter: David Neuman
>
> When Traffic Router reloads SSL certificates while processing HTTPS 
> transactions, the TPS drops significantly. 
> Example Log output during the drop in TPS: 
> INFO  2016-11-07T14:05:23.363 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: 
> https://to.kabletown.net/api/1.2/cdns/name/test-xc
> r/sslkeys.json; timeout is 15000
> INFO  2016-11-07T14:05:23.500 [New I/O worker #8] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.ConfigHandler - 
> Entered processConfig
> INFO  2016-11-07T14:05:23.500 [New I/O worker #8] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.ConfigHandler - 
> Exiting processConfig: No json data to process
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-02 domain ds-02.cdn.kabletown.net.net
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-01 domain ds-01.cdn.kabletown.net.net
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-05 domain ds-05.cdn.kabletown.net.net
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-04 domain ds-04.cdn.kabletown.net.net
> ERROR 2016-11-07T14:05:24.760 [Thread-5] 
> com.comcast.cdn.traffic_control.traffic_router.core.config.CertificateChecker 
> - No certificate data for https cdn-ds-03 domain ds-03.cdn.kabletown.net.net
> INFO  2016-11-07T14:05:43.399 [pool-17-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: 
> https://to.kabletown.net/api/1.1/cdns/name/test-xcr/dnsseckeys.json; timeout 
> is 3
> INFO  2016-11-07T14:06:23.339 [pool-5-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.monitor.TrafficMonitorWatcher
>  - Loading properties from /opt/traffic_router/conf/traffic_monitor.properties



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-57) Build process not changing directory and reading configuration file

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-57:
--
Labels: build  (was: )

> Build process not changing directory and reading configuration file
> ---
>
> Key: TC-57
> URL: https://issues.apache.org/jira/browse/TC-57
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Monitor
>Affects Versions: 1.9.0
> Environment: Vagrant + Centos 6.8 or Centos 7.2
>Reporter: Steve Malenfant
>Priority: Minor
>  Labels: build
>
> Followed direction posted on the Traffic Monitor Developer’s Guide but I 
> couldn't seem to get Traffic Monitor test to work.
> Using ~/build/build.sh fails to build Traffic Monitor
> Using ~/build/build.sh traffic_monitor works but tests aren't working
> Using cd traffic_monitor; ./build/build/build_rpm.sh seems to compile maven 
> but fails to find valid configuration file
> I don't think I've successfully been able to run Traffic Monitor tests in the 
> past and my environment might be incorrect.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-59) Traffic Ops Client should return HTTP body on Error response

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-59:
--
Labels: error_response  (was: )

> Traffic Ops Client should return HTTP body on Error response
> 
>
> Key: TC-59
> URL: https://issues.apache.org/jira/browse/TC-59
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops Client , Traffic Portal
>Reporter: David Neuman
>  Labels: error_response
>
> Currently, if the Traffic Ops client gets back an Error response from TO, the 
> calling method is returned a struct containing the StatusCode and Status 
> (https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/client/traffic_ops.go#L180).
>   Sometimes there is useful information in the body of the response as well - 
> such as why an error occured -- so it would be useful to return the body to 
> the calling method as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-64) Experimental SPA application

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-64:
--
Labels: spa  (was: )

> Experimental SPA application
> 
>
> Key: TC-64
> URL: https://issues.apache.org/jira/browse/TC-64
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Ops API, Traffic Portal
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>  Labels: spa
>
> At the 2016 Traffic Control summit, a prototype of a SPA application 
> developed by [~mitchell...@apache.org] using AngularJS was demo'd that works 
> entirely on top of the TO API.
> This issue is a placeholder for any work done to this prototype / 
> experimental UI. The goal is to replicate the functionality of the current 
> MVC TO UI. nothing more, nothing less.
> This will require some additions to the TO API. look for issues regarding 
> each API addition.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TC-70) Upgrade Tomcat Version for Traffic Monitor

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey closed TC-70.
-
Resolution: Fixed

Duplicate

> Upgrade Tomcat Version for Traffic Monitor
> --
>
> Key: TC-70
> URL: https://issues.apache.org/jira/browse/TC-70
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Monitor
>Reporter: David Neuman
>
> Traffic Monitor currently uses tomcat 6.0.33, this version of Tomcat will be 
> EOL soon, so we need to update to a newer (latest?) version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-69) Upgrade Tomcat Version for Traffic Router

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-69:
--
Labels: tomcat  (was: )

> Upgrade Tomcat Version for Traffic Router
> -
>
> Key: TC-69
> URL: https://issues.apache.org/jira/browse/TC-69
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Reporter: David Neuman
>Assignee: David Neuman
>  Labels: tomcat
>
> Traffic Router currently uses tomcat 6.0.33, this version of Tomcat will be 
> EOL soon, so we need to update to a newer (latest?) version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-76) astats-over-http assumes interface bonding

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-76:
--
Labels: astats interface_bonding  (was: )

> astats-over-http assumes interface bonding
> --
>
> Key: TC-76
> URL: https://issues.apache.org/jira/browse/TC-76
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Monitor
>Affects Versions: 1.7.0
>Reporter: Amir Yeshurun
>Priority: Minor
>  Labels: astats, interface_bonding
>
> astats-over-http tries to read interface speed at 
> /sys/class/net//slave_
> Will return zero if not found, causing traffic monitor to mis-calculate 
> available bandwidth.
> Suggested workaround (not tested yet) - use a simple bond with just one NIC 
> as a slave.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-90) TR should check for closest cache group because using Maxmind Geolocation

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-90:
--
Labels: cache_group routing  (was: )

> TR should check for closest cache group because using Maxmind Geolocation
> -
>
> Key: TC-90
> URL: https://issues.apache.org/jira/browse/TC-90
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 1.8.0
>Reporter: Eric Friedrich
>Priority: Minor
>  Labels: cache_group, routing
>
> Problem Statement: 
> 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). 
> With Jeff's proposed fix below, instead of going to the geolocation provider, 
> TR would find the cache group closest to the CZF "hit" cache group. 
> From Jeff Elsoo:
> 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.
> dev@ Discussion Thread: 
> https://lists.apache.org/thread.html/b033b3943c22a606370ad3981fa05fb0e7039161b88bbc035bc49b25@%3Cdev.trafficcontrol.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-90) TR should check for closest cache group because using Maxmind Geolocation

[Ryan Durfey (JIRA)]

[ 
https://issues.apache.org/jira/browse/TC-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049635#comment-16049635
 ] 

Ryan Durfey commented on TC-90:
---

Is this resolved?

> TR should check for closest cache group because using Maxmind Geolocation
> -
>
> Key: TC-90
> URL: https://issues.apache.org/jira/browse/TC-90
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 1.8.0
>Reporter: Eric Friedrich
>Priority: Minor
>  Labels: cache_group, routing
>
> Problem Statement: 
> 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). 
> With Jeff's proposed fix below, instead of going to the geolocation provider, 
> TR would find the cache group closest to the CZF "hit" cache group. 
> From Jeff Elsoo:
> 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.
> dev@ Discussion Thread: 
> https://lists.apache.org/thread.html/b033b3943c22a606370ad3981fa05fb0e7039161b88bbc035bc49b25@%3Cdev.trafficcontrol.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-152) misc/release.pl incorrectly updates the VERSION file

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-152:
---
Labels: easyfix release.pl  (was: easyfix)

> misc/release.pl incorrectly updates the VERSION file
> 
>
> Key: TC-152
> URL: https://issues.apache.org/jira/browse/TC-152
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Release
>Affects Versions: 2.0.0
>Reporter: Dan Kirkwood
>Priority: Trivial
>  Labels: easyfix, release.pl
> Fix For: 2.0.0
>
>
> for 1.8.0-RC10,  I ran `misc/release.pl ... cut` to create the git tag, sign 
> it,  etc..
> Unfortunately,  we found one more change to be made,  so I ran the same 
> command with a `cleanup` argument instead,  then another `... cut`.   I think 
> the `cleanup`  decremented the VERSION file in master.
> I think we ought to handle the VERSION file separately from this script,  so 
> it should not modify VERSION at all..



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-108) sync_ts_database: Requires lots of memory to copy database

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-108:
---
Labels: sync_ts_database  (was: )

> sync_ts_database: Requires lots of memory to copy database
> --
>
> Key: TC-108
> URL: https://issues.apache.org/jira/browse/TC-108
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Stats
>Affects Versions: 1.8.0
> Environment: 32GB server (about 20+GB available memory) running 
> traffic_stats
>Reporter: Steve Malenfant
>Priority: Trivial
>  Labels: sync_ts_database
>
> During a migration from InfluxDB 0.13.3 to 1.1, we copied our entire database 
> using the sync_ts_database. Somehow the process takes a long time due all 
> memory+swap being used. As far as I know it doesn't get killed but the 
> process  seems to never finish (I'm probably being impatient after 30 
> minutes).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-153) URL Signing Plugin - Query String Hashing Override Option

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-153:
---
Component/s: (was: Traffic Server Plugin - astats_over_http)
 Traffic Server Plugins

> URL Signing Plugin - Query String Hashing Override Option
> -
>
> Key: TC-153
> URL: https://issues.apache.org/jira/browse/TC-153
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Server Plugins
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>  Labels: query_strings, url_signing
>
> When using query string URL signing, if the client adds any additional  query 
> strings to the URL, these are ALWAYS considered in the URL hash regardless of 
> the use parts settings.
> When using pathparams URL signing, if the client adds query string parameters 
> to the URL they are NEVER considered in the URL hash regardless of the use 
> parts settings.
> Provide a signing option which allows users to override the default behavior 
> and include or exclude custom query strings in the URL signature hash. 
> Standard behavior could remain as is and this new parameter would allow users 
> to override the standard behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-157) Failed to restart tomcat in Traffic Router when failed to get SSL keys

[Ryan Durfey (JIRA)]

[ 
https://issues.apache.org/jira/browse/TC-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049625#comment-16049625
 ] 

Ryan Durfey commented on TC-157:


Is this resolved?

> Failed to restart tomcat in Traffic Router when failed to get SSL keys
> --
>
> Key: TC-157
> URL: https://issues.apache.org/jira/browse/TC-157
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 1.7.0
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>  Labels: ssl, tomcat
>
> Stopping tomcat failed with the following log:
> WARN  2017-02-17T09:00:05.939 [main] 
> com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesPublisher
>  - Detected destroy setting running to false
> INFO  2017-02-17T09:00:05.943 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesClient 
> - Interrupted while pausing for check of traffic ops config
> INFO  2017-02-17T09:00:05.943 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - POSTing: 
> https://192.168.122.181/api/1.1/user/login; timeout is 15000
> INFO  2017-02-17T09:00:06.005 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: 
> https://192.168.122.181/api/1.2/cdns/name/kabletown_cdn/sslkeys.jso
> n; timeout is 15000
> WARN  2017-02-17T09:00:06.040 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - Failed 
> Http Request to https://192.168.122.181/api/1.2/cdns/name/kabletown_
> cdn/sslkeys.json Status 400



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-157) Failed to restart tomcat in Traffic Router when failed to get SSL keys

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-157:
---
Labels: ssl tomcat  (was: )

> Failed to restart tomcat in Traffic Router when failed to get SSL keys
> --
>
> Key: TC-157
> URL: https://issues.apache.org/jira/browse/TC-157
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 1.7.0
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>  Labels: ssl, tomcat
>
> Stopping tomcat failed with the following log:
> WARN  2017-02-17T09:00:05.939 [main] 
> com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesPublisher
>  - Detected destroy setting running to false
> INFO  2017-02-17T09:00:05.943 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesClient 
> - Interrupted while pausing for check of traffic ops config
> INFO  2017-02-17T09:00:05.943 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - POSTing: 
> https://192.168.122.181/api/1.1/user/login; timeout is 15000
> INFO  2017-02-17T09:00:06.005 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: 
> https://192.168.122.181/api/1.2/cdns/name/kabletown_cdn/sslkeys.jso
> n; timeout is 15000
> WARN  2017-02-17T09:00:06.040 [pool-2-thread-1] 
> com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - Failed 
> Http Request to https://192.168.122.181/api/1.2/cdns/name/kabletown_
> cdn/sslkeys.json Status 400



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-159) traffic_monitor_config.js is corrupt.

[Ryan Durfey (JIRA)]

[ 
https://issues.apache.org/jira/browse/TC-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049624#comment-16049624
 ] 

Ryan Durfey commented on TC-159:


Is this resolved?

> traffic_monitor_config.js is corrupt.
> -
>
> Key: TC-159
> URL: https://issues.apache.org/jira/browse/TC-159
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Monitor
>Affects Versions: 1.8.0
>Reporter: Chris Lemmons
>Assignee: Eric Friedrich
>Priority: Minor
>  Labels: easyfix, traffic_monitor_config.js
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The traffic_monitor_config.js file that is installed with the RPM is invalid. 
> The license header comment was added to the top of the file, but JSON files 
> aren't legally allowed to have comments, so the file fails to load.
> Workaround: Remove the header and everything runs fine.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-166) lastConfigCheck stat should be updated if CrConfigs have a different checksum but the same timestamp

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-166:
---
Labels: crconfig  (was: )

> lastConfigCheck stat should be updated if CrConfigs have a different checksum 
> but the same timestamp
> 
>
> Key: TC-166
> URL: https://issues.apache.org/jira/browse/TC-166
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Router
>Affects Versions: 2.0.0
>Reporter: David Neuman
>Priority: Minor
>  Labels: crconfig
>
> When Traffic Router checks for a new CrConfig it first checks to see if the 
> CrConfig returned from Traffic Monitor has the same checksum as it's current 
> version, if it doesn't then Traffic Router attempts to process it.  During 
> processing, if the new CrConfig has the same timestamp as the current 
> CrConfig, Traffic Router logs and info message and returns false.  A warning 
> is then logged saying CrConfig has been rejected.  This is ok, however, the 
> lastConfigCheck stat is not updated.  Since the CrConfigs are the same, the 
> lastConfigCheck stat should be updated.
> This is basically an edge case that we came across because we are running 
> javaTM and goTM in parallel.  The lastConfigCheck stat was only being updated 
> once every other poll, which cause our alarms to go off.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-173) API on port 3333 doesn't start if 443 is first in server.xml

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-173:
---
Labels: api_port server.xml  (was: )

> API on port  doesn't start if 443 is first in server.xml
> 
>
> Key: TC-173
> URL: https://issues.apache.org/jira/browse/TC-173
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 1.8.0, 1.7.0
> Environment: CentOS 6
>Reporter: Hank Beatty
>Priority: Minor
>  Labels: api_port, server.xml
>
> I didn't have any certs installed on the Traffic Router so the https portion 
> couldn't start.
> It was suggested that TR should check to see if there are certs before trying 
> to start 443 connector.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-192) Java TM and Go TM get build with exact same RPM Name

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-192:
---
Labels: build gotm javatm  (was: )

> Java TM and Go TM get build with exact same RPM Name
> 
>
> Key: TC-192
> URL: https://issues.apache.org/jira/browse/TC-192
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Monitor, Traffic Monitor (golang)
>Affects Versions: 2.0.0, 2.1.0
>Reporter: David Neuman
>  Labels: build, gotm, javatm
>
> When building Traffic Control, goTM and javaTM get build with the exact same 
> rpm name.  This means that if you are building all projects you only get one 
> TM RPM and its whichever one built last.  The names should be updated so that 
> they are not the same.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-195) Traffic Router requires status to be set to OFFLINE to remove an active Traffic Router

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-195:
---
Labels: crconfig routing  (was: )

> Traffic Router requires status to be set to OFFLINE to remove an active 
> Traffic Router
> --
>
> Key: TC-195
> URL: https://issues.apache.org/jira/browse/TC-195
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 2.1.0
>Reporter: Jeff Elsloo
>Assignee: Jeff Elsloo
>Priority: Minor
>  Labels: crconfig, routing
>
> Traffic Router currently requires the status of a given Traffic Router to be 
> set to OFFLINE if it is to be removed from DNS answers. When set to OFFLINE, 
> Traffic Ops will drop it from the CrConfig, so naturally it would drop from 
> the configuration. If, however, a Traffic Router is set to ADMIN_DOWN, it 
> remains in the CrConfig and Traffic Router leaves it in the DNS zones because 
> the status is not OFFLINE.
> Ideally, instead of checking if the status is OFFLINE, we would check to see 
> if it's a "positive" status (ONLINE or REPORTED). Any other status should be 
> considered invalid and the Traffic Router should be skipped with regard to 
> DNS.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-197) File descriptor leak caused by NIO protocol connector

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-197:
---
Labels: file_descriptor_leak  (was: )

> File descriptor leak caused by NIO protocol connector
> -
>
> Key: TC-197
> URL: https://issues.apache.org/jira/browse/TC-197
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 2.1.0
>Reporter: Jeff Elsloo
>  Labels: file_descriptor_leak
> Attachments: Screen Shot 2017-03-15 at 2.12.58 PM.png
>
>
> The new default configuration for Traffic Router and Tomcat is to use the 
> {{Http11NioProtocol}} adapter over the previous {{Http11Protocol}} adapter. 
> This is accomplished via the {{LanguidNioProtocol}} connectors specified in 
> Tomcat's {{server.xml}}.
> We observed a file descriptor leak with connections, but have not dug into 
> the cause. We observed roughly 30-40k connections in {{CLOSE_WAIT}} which 
> caused the machine to exhaust its file descriptors based upon configured 
> limits. We also observed a similar growth curve on total threads, so 
> something is not behaving and being cleaned up appropriately.
> The cause could range from a bug in the {{Http11NioProtocol}} connector due 
> to the ancient version of Tomcat we're using, tuning within the connector 
> itself (max threads, intervals, etc), tuning within the JVM (memory, GC, 
> etc), or at the OS level (kernel params around TCP connections, etc).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-209) Experimental Traffic Monitor polling OFFLINE caches

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-209:
---
Labels: health_monitoring polling  (was: )

> Experimental Traffic Monitor polling OFFLINE caches
> ---
>
> Key: TC-209
> URL: https://issues.apache.org/jira/browse/TC-209
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Monitor (golang)
>Affects Versions: 2.0.0
>Reporter: Jeff Elsloo
>Assignee: Robert Butts
>Priority: Minor
>  Labels: health_monitoring, polling
>
> The experimental (golang) version of Traffic Monitor appears to be polling 
> {{OFFLINE}} caches.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-210) User agent and application versions incorrect

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-210:
---
Labels: user_agent  (was: )

> User agent and application versions incorrect
> -
>
> Key: TC-210
> URL: https://issues.apache.org/jira/browse/TC-210
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Monitor (golang)
>Reporter: Jeff Elsloo
>Assignee: Robert Butts
>Priority: Minor
>  Labels: user_agent
>
> The experimental (golang) Traffic Monitors appear to have a hardcoded version 
> in the user agent string. This shouldn't really be hardcoded, or if it is, 
> should be search/replaced at compile-time.
> {{common/fetcher/fetcher.go:  req.Header.Set("User-Agent", 
> "traffic_monitor/1.0") // TODO change to 2.0?}}
> Additionally, the version served up by the application does not match the RPM 
> version.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-284) Strip "actionable" query strings

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-284:
---
Labels: query_strings  (was: )

> Strip "actionable" query strings
> 
>
> Key: TC-284
> URL: https://issues.apache.org/jira/browse/TC-284
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Router
>Affects Versions: 2.0.0
>Reporter: Jeff Elsloo
>Priority: Minor
>  Labels: query_strings
>
> If an "actionable" query string is present in the incoming URL, strip it to 
> prevent duplication of object storage in case the delivery service's setting 
> is to consider the qstring at the edge. If it is, leaving the qstring in 
> place will potentially cause the same object to be stored twice; one object 
> with the "actionable" TR query parameters and one without, if there are 
> clients that make both types of requests.
> Specific query strings are {{?format=json}}, {{?trred=false}}, and 
> {{?fakeClientIpAddress=foo}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-286) Create UI for default DNS for GenIso.

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-286:
---
Component/s: Traffic Ops

> Create UI for default DNS for GenIso.
> -
>
> Key: TC-286
> URL: https://issues.apache.org/jira/browse/TC-286
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: David Neuman
>Priority: Minor
>  Labels: genlso, resolve.conf
>
> This is an update to issue #55. In the current patch it reads the DNS servers 
> from /etc/resolv.conf on the Traffic Ops server. Ideally there would be a way 
> to set two default DNS servers through the Web UI and a way to override them 
> on either the (or both) physical location field or the cache group field.
> While we're at it, there are some other defaults in GenIso.pm that probably 
> should be editable via the interface:
> 23 my $filebasedir = "/var/www/files";
> 24 my $ksfiles_parm_name = "kickstart.files.location";
> 25 my $ksfiles_configfile_name = "mkisofs";
> 26
> 27 # This is the directory we put the configuration files in for kickstart &
> 28 # scripts to process:-
> 29 my $install_cfg = "ks_scripts";
> moving from:  https://github.com/Comcast/traffic_control/issues/78



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-286) Create UI for default DNS for GenIso.

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-286:
---
Labels: genlso resolve.conf  (was: )

> Create UI for default DNS for GenIso.
> -
>
> Key: TC-286
> URL: https://issues.apache.org/jira/browse/TC-286
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: David Neuman
>Priority: Minor
>  Labels: genlso, resolve.conf
>
> This is an update to issue #55. In the current patch it reads the DNS servers 
> from /etc/resolv.conf on the Traffic Ops server. Ideally there would be a way 
> to set two default DNS servers through the Web UI and a way to override them 
> on either the (or both) physical location field or the cache group field.
> While we're at it, there are some other defaults in GenIso.pm that probably 
> should be editable via the interface:
> 23 my $filebasedir = "/var/www/files";
> 24 my $ksfiles_parm_name = "kickstart.files.location";
> 25 my $ksfiles_configfile_name = "mkisofs";
> 26
> 27 # This is the directory we put the configuration files in for kickstart &
> 28 # scripts to process:-
> 29 my $install_cfg = "ks_scripts";
> moving from:  https://github.com/Comcast/traffic_control/issues/78



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TC-288) Routing name/entry point in CRConfig #61

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey closed TC-288.
--
Resolution: Fixed

Duplicate of TC-287

> Routing name/entry point in CRConfig #61
> 
>
> Key: TC-288
> URL: https://issues.apache.org/jira/browse/TC-288
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Reporter: Jan van Doorn
>Priority: Minor
>  Labels: crconfig, routing
>
> A default routing name/entry point should be added as a profile parameter, 
> and this parameter should be used by default as the value of the "routing 
> name" or "entry point" on the delivery service in the CRConfig. This value 
> should be overridable on a per-delivery service level, which means that the 
> delivery service UIs should be enhanced to provide this capability and to 
> display the default value. See also  
> https://github.com/Comcast/traffic_control/issues/61 for some of the Crystal 
> hacks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-288) Routing name/entry point in CRConfig #61

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-288:
---
Labels: crconfig routing  (was: )

> Routing name/entry point in CRConfig #61
> 
>
> Key: TC-288
> URL: https://issues.apache.org/jira/browse/TC-288
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Reporter: Jan van Doorn
>Priority: Minor
>  Labels: crconfig, routing
>
> A default routing name/entry point should be added as a profile parameter, 
> and this parameter should be used by default as the value of the "routing 
> name" or "entry point" on the delivery service in the CRConfig. This value 
> should be overridable on a per-delivery service level, which means that the 
> delivery service UIs should be enhanced to provide this capability and to 
> display the default value. See also  
> https://github.com/Comcast/traffic_control/issues/61 for some of the Crystal 
> hacks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TC-392) Log aggregation in 1 min intervals for delivery service charting

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-392:
--

 Summary: Log aggregation in 1 min intervals for delivery service 
charting
 Key: TC-392
 URL: https://issues.apache.org/jira/browse/TC-392
 Project: Traffic Control
  Issue Type: Bug
  Components: Traffic Logs, Traffic Ops API, Traffic Portal
Reporter: Ryan Durfey


Today, log aggregation is performed in a separate commercial system.  This 
should be done in an open source system and aggregated into a an open source 
time series database.

Once traffic logs is complete, we should begin aggregating logs on 1 min 
intervals for charting and graphing in a time series database like influx.db.
Key Fields to aggregate:
bandwidith, tps, http codes, crc, tier, etc...  

Start with what exists in the portal today.  We would also like to expand on 
this based on our monitoring experience.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-307) Need remap stats by host in Influx

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-307:
---
Labels: astats log_aggregation  (was: )

> Need remap stats by host in Influx
> --
>
> Key: TC-307
> URL: https://issues.apache.org/jira/browse/TC-307
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Stats
>Reporter: Jan van Doorn
>Priority: Minor
>  Labels: astats, log_aggregation
>
> Traffic Stats should store status codes by host. Ideally this would be by 
> host and deliveryservice so that you could find status codes for a DS per 
> cache. Traffic Monitor seems to have all the data necessary, just need to get 
> Traffic Stats to gather, parse, and write to Influxdb. From 
> https://github.com/Comcast/traffic_control/issues/1372



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-310) Parts of URL to hash on should be configurable per delivery service

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-310:
---
Labels: routing url_hash  (was: )

> Parts of URL to hash on should be configurable per delivery service
> ---
>
> Key: TC-310
> URL: https://issues.apache.org/jira/browse/TC-310
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Router
>Reporter: Jan van Doorn
>Priority: Minor
>  Labels: routing, url_hash
>
> Traffic Ops, Traffic Router will need updates for this -- currently Traffic 
> Router hashes on the whole URL (short of the query parameters).
> Config might be similar to what is done for URL signing -- "useparts = 0110"
> From https://github.com/Comcast/traffic_control/issues/1455



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-311) Change Traffic Monitor 2.0 Query Parameter Filter to a single interface

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-311:
---
Labels: cachestats dsstats  (was: )

> Change Traffic Monitor 2.0 Query Parameter Filter to a single interface
> ---
>
> Key: TC-311
> URL: https://issues.apache.org/jira/browse/TC-311
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Monitor (golang)
>Reporter: Robert Butts
>Assignee: Robert Butts
>Priority: Minor
>  Labels: cachestats, dsstats
>
> Technical Debt.
> Currently, DsStats and CacheStats have separate but very similar Filter 
> interfaces. These should be combined, if possible. If it isn't possible, at 
> least their duplicate logic should be combined to a single function.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-316) Create Traffic Monitor 2.0 API Version Two

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-316:
---
Labels: api_endpoints  (was: )

Consider this in the new version 
https://cwiki.apache.org/confluence/display/TC/API+Guidelines

> Create Traffic Monitor 2.0 API Version Two
> --
>
> Key: TC-316
> URL: https://issues.apache.org/jira/browse/TC-316
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Monitor (golang)
>Reporter: Robert Butts
>Priority: Minor
>  Labels: api_endpoints
>
> Traffic Monitor 2.0 must implement the current API from 1.0, so existing 
> integrations (Traffic Router, Traffic Stats) will work.
> But we'd like to make a more modern API, which other apps can later be moved 
> to.
> Proposed goals:
> More well-known paths. Current path is /publish/X, suggest /api/X.
> Consider versioning, e.g. /api/v2/. Also consider not versioning, since 
> the 1.0 API is not at /api/. it looks like a lot of products seem to get it 
> right the second time. There seem to be a lot of "version 2" APIs out there 
> (Stripe, Slack). Maybe we should not version and guess this will be final, 
> for its data. Alternatively, we could version, /api/v2/, and also link /api/ 
> to the current version. Then, if we feel there won't be a version 3 after 
> some time, /api/v2/ could be deprecated.
> More structure. For example. the current API for Delivery Service stats 
> returns {"deliveryService": {"adcolony": {"location.us-al-malt.error-string": 
> {"value": "foo"}, "location.us-al-malt.in_bytes": {"value":24} ...
> This could be changed to
> {"deliveryService": {"adcolony": {"location": {"us-al-malt": 
> {"error-string": {"value": "foo"}, "in_bytes": {"value": 24} ...
> To reduce duplicate text, make messages smaller, and make the message 
> easier to read for both humans and computers, and in a structure more 
> suitable for representation in the code. For example, 
> "location.us-al-malt.in_bytes" requires custom string parsing to isolate each 
> part, whereas putting each part in JSON keys allows standard JSON library 
> parsing.
> Add CSV responses. CSV is significantly faster to parse, and with the 
> size of our data, it might make a relevant difference in application 
> performance. We should consider both CSV for existing endpoints requested 
> with an Accept: text/csv header, and new endpoints with smaller and 
> two-dimensional data.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-319) Need Localized Traffic Router

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-319:
---
Labels: localization  (was: Localization)

> Need Localized Traffic Router
> -
>
> Key: TC-319
> URL: https://issues.apache.org/jira/browse/TC-319
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Reporter: Jan van Doorn
>Assignee: Jeff Elsloo
>Priority: Minor
>  Labels: localization
>
> Jeff has a POC, and an idea in his head. 
> From https://github.com/Comcast/traffic_control/issues/1771



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-328) server Network IP expect to be different management GH #1618

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-328:
---
Labels: configuration validation  (was: Configuration)

> server Network IP expect to be different management GH #1618
> 
>
> Key: TC-328
> URL: https://issues.apache.org/jira/browse/TC-328
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Portal
>Reporter: Dewayne Richardson
>  Labels: configuration, validation
>
> when you add or edit server at the GUI of traffic_ops,server Network IP can 
> be same as management IP Address .
>   pengyuewu opened this issue on Jul 21, 2016 · 0 comments



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-330) Documentation: Configuration Traffic Ops, add domain_name definition

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-330:
---
Labels: documentation domain_name  (was: )

> Documentation: Configuration Traffic Ops, add domain_name definition
> 
>
> Key: TC-330
> URL: https://issues.apache.org/jira/browse/TC-330
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Eric Friedrich
>Priority: Minor
>  Labels: documentation, domain_name
>
> Seems like there is no documentation about the "domain_name". Note to add in 
> the "Configuration" section of Traffic Ops.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TC-335) Traffic Router should not bring unresponsive Traffic Monitor decisions back right away GH #1661

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey closed TC-335.
--
Resolution: Fixed

Duplicate of TC-339

> Traffic Router should not bring unresponsive Traffic Monitor decisions back 
> right away GH #1661
> ---
>
> Key: TC-335
> URL: https://issues.apache.org/jira/browse/TC-335
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Reporter: Dewayne Richardson
>
> Traffic Monitor split-brain scenario can have a violent recovery path -- 
> potentially taking marking all caches unhealthy.
>   mtorluemke opened this issue on Jul 29, 2016 · 1 comment



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-336) Add ability to copy url_sig keys from one DS to another GH #1540

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-336:
--

Assignee: Dylan Volz

> Add ability to copy url_sig keys from one DS to another GH #1540
> 
>
> Key: TC-336
> URL: https://issues.apache.org/jira/browse/TC-336
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Vault
>Reporter: Dewayne Richardson
>Assignee: Dylan Volz
>Priority: Minor
>  Labels: keys, url_signing
>
> There are some cases where we want to use the same URL sig keys for multiple 
> delivery services. Currently this is handled by using cURL and other manual 
> processes. Traffic Ops should support the ability to copy url sig keys from 
> one DS to another. When this happens Traffic Ops should also create the 
> necessary parameters for the target DS so that URL signing works.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-339) Traffic Router should not bring unresponsive Traffic Monitor decisions back right away

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-339:
---
Labels: health_monitoring  (was: )

> Traffic Router should not bring unresponsive Traffic Monitor decisions back 
> right away
> --
>
> Key: TC-339
> URL: https://issues.apache.org/jira/browse/TC-339
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Reporter: Zhilin Huang
>  Labels: health_monitoring
>
> Traffic Monitor split-brain scenario can have a violent recovery path -- 
> potentially taking marking all caches unhealthy.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-347) Docker Build for Portal fails with SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://rubygems.org/latest_specs.4.8.gz

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-347:
---
Labels: build docker  (was: )

> Docker Build for Portal fails with SSL_connect returned=1 errno=0 state=SSLv3 
> read server certificate B: certificate verify failed 
> (https://rubygems.org/latest_specs.4.8.gz
> 
>
> Key: TC-347
> URL: https://issues.apache.org/jira/browse/TC-347
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Portal
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>  Labels: build, docker
>
> Attempting to build the rpms and the build fails at the Portal phase.
> ---
> Step 6/10 : RUN gem install compass
>  ---> Running in 5f883ef539c1
> ERROR:  Could not find a valid gem 'compass' (>= 0), here is why:
>   Unable to download data from https://rubygems.org/ - SSL_connect 
> returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify 
> failed (https://rubygems.org/latest_specs.4.8.gz)
> ERROR: Service 'traffic_portal_build' failed to build: The command '/bin/sh 
> -c gem install compass' returned a non-zero code: 2



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-360) astats IPv6 and IPv4 access list behavior inconsistency

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-360:
---
Component/s: (was: Traffic Server Plugin - astats_over_http)
 Traffic Server Plugins

> astats IPv6 and IPv4 access list behavior inconsistency
> ---
>
> Key: TC-360
> URL: https://issues.apache.org/jira/browse/TC-360
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Server Plugins
>Affects Versions: 2.0.0
>Reporter: Jeff Elsloo
>Priority: Minor
>  Labels: allow_ip, allow_ip6, astats
>
> The behavior of the access configuration parameter for astats is 
> inconsistent. When {{allow_ip}} is present with no arguments, or is missing, 
> requests into astats are denied with a 404 not found. The {{allow_ip6}} 
> parameter is the opposite. When present with no arguments, or missing, 
> requests into astats are served. When an IP list is present in either case, 
> access is denied unless one's source address is within the specified list of 
> subnets.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-367) Download page must not link to dist.apache.org

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-367:
---
Labels: documentation links  (was: Links)

> Download page must not link to dist.apache.org
> --
>
> Key: TC-367
> URL: https://issues.apache.org/jira/browse/TC-367
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Sebb
>  Labels: documentation, links
>
> The dist.apache.org SVN area is only intended as the staging area for the ASF 
> mirror service.
> Please do not link to files on it from download pages.
> Sigs and hashes should link to:
> https://www.apache.org/dist/incubator/trafficcontrol/
> instead. And later to
> https://www.apache.org/dist/trafficcontrol/
> Also the download page needs an https link to the KEYS file 
> https://www.apache.org/dist/incubator/trafficcontrol/KEYS
> and some instructions on how to check sigs or hashes.
> Please see:
> http://www.apache.org/dev/release-publishing.html#distribution_dist



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-366) Improve misc/release.pl to do more release management tasks

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-366:
---
Labels: build release.pl  (was: build)

> Improve misc/release.pl to do more release management tasks
> ---
>
> Key: TC-366
> URL: https://issues.apache.org/jira/browse/TC-366
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Release
>Affects Versions: 2.0.0
>Reporter: Eric Friedrich
>Priority: Minor
>  Labels: build, release.pl
>
> Today misc/release.pl does the following: 
> 1) Updates VERSION file
> 2) Creates and pushes a signed git tag
> It would be nice if misc/release.pl also did the following
> 1) Create release tarball by calling docker-compose 
> 2) Unpack release tarball and run docker-compose build. Verify RPMs are 
> built. 
> 2) Create gpg armormed sig by running `gpg --armor --detach-sig 
> incubator-trafficcontrol-.tgz`
> 2a) Verify signature with gpg --verify 
> incubator-trafficcontrol-.tgz.asc
> 3) Create MD5 and SHA512 signatures with:
> `md5sum incubator-trafficcontrol-.tgz > 
> incubator-trafficcontrol-.tgz.md5
> shasum -a512 incubator-trafficcontrol-.tgz > 
> incubator-trafficcontrol-.tgz.sha512`
> 3a) Check signatures with :
> `md5sum -c incubator-trafficcontrol-.tgz.md5
> shasum -c incubator-trafficcontrol-.tgz.sha512`



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-373) Traffic Stats Has Connection Leak

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-373:
---
Labels: connections  (was: )

> Traffic Stats Has Connection Leak 
> --
>
> Key: TC-373
> URL: https://issues.apache.org/jira/browse/TC-373
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Stats
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>  Labels: connections
>
> Happens when TO not response 200 OK to traffic stats:
> [ERROR] 2017-06-08 09:54:40 500 Internal Server Error[500] - Error requesting 
> Traffic Ops https://coffee-ops-a.coffee.com/api/1.2/stats_summary/create
> $ sudo netstat -tunp|grep traffic_stats|head 
> tcp   32  0 10.63.115.225:39667 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:50388 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:46896 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:38896 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp1  0 10.63.115.225:53682 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:42324 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:39618 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:36613 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:51851 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:52842 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-373) Traffic Stats Has Connection Leak

[Ryan Durfey (JIRA)]

[ 
https://issues.apache.org/jira/browse/TC-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049570#comment-16049570
 ] 

Ryan Durfey commented on TC-373:


Has this been resolved?


> Traffic Stats Has Connection Leak 
> --
>
> Key: TC-373
> URL: https://issues.apache.org/jira/browse/TC-373
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Stats
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>
> Happens when TO not response 200 OK to traffic stats:
> [ERROR] 2017-06-08 09:54:40 500 Internal Server Error[500] - Error requesting 
> Traffic Ops https://coffee-ops-a.coffee.com/api/1.2/stats_summary/create
> $ sudo netstat -tunp|grep traffic_stats|head 
> tcp   32  0 10.63.115.225:39667 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:50388 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:46896 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:38896 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp1  0 10.63.115.225:53682 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:42324 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:39618 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:36613 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:51851 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats   
> tcp   32  0 10.63.115.225:52842 10.63.115.224:443   
> CLOSE_WAIT  795/traffic_stats 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-389) pkg build script should be more helpful

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-389:
---
 Labels: build_script docker  (was: )
Component/s: Traffic Ops

> pkg build script should be more helpful
> ---
>
> Key: TC-389
> URL: https://issues.apache.org/jira/browse/TC-389
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Dan Kirkwood
>  Labels: build_script, docker
>
> Tried out the ./pkg build script with docker and docker-compose properly 
> installed.
> It failed, but gave me no information whatsoever.  Also,  no dist directory,  
> so no log files from docker-compose:
> {code}
> $ ./pkg source traffic_ops_build
> Building source.
> Building traffic_ops_build.
> Failed to build source traffic_ops_build.
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-390) Update package structure for Traffic Router

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-390:
---
Labels: package_structure  (was: )

> Update package structure for Traffic Router
> ---
>
> Key: TC-390
> URL: https://issues.apache.org/jira/browse/TC-390
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Reporter: David Neuman
>Priority: Minor
>  Labels: package_structure
>
> Traffic Router's package structure is currently 
> com.comcast.cdn.traffic_control.traffic_router, since we have moved to apache 
> it should be org.apache.traffic_control.traffic_router.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-36) Split query string option from cache key / parent selection

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-36:
--
Summary: Split query string option from cache key / parent selection  (was: 
Traffic Ops -- split query string option )

> Split query string option from cache key / parent selection
> ---
>
> Key: TC-36
> URL: https://issues.apache.org/jira/browse/TC-36
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Affects Versions: 1.8.0
>Reporter: Mark Torluemke
>  Labels: cache_key, parent_selection, query_strings
>
> Currently, a single delivery service field in Traffic Ops controls both the 
> cache key behavior, and the parent selection behavior. There are often use 
> cases for combinations that don't currently exist, so the best option is 
> likely to split it into different fields.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-36) Split query string option from cache key / parent selection

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-36:
--
Labels: cache_key parent_selection query_strings  (was: cache_key 
parent_selection)

> Split query string option from cache key / parent selection
> ---
>
> Key: TC-36
> URL: https://issues.apache.org/jira/browse/TC-36
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Affects Versions: 1.8.0
>Reporter: Mark Torluemke
>  Labels: cache_key, parent_selection, query_strings
>
> Currently, a single delivery service field in Traffic Ops controls both the 
> cache key behavior, and the parent selection behavior. There are often use 
> cases for combinations that don't currently exist, so the best option is 
> likely to split it into different fields.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-48) Steering Delivery Test Cases

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-48:
--
Labels: api_steering_internal  (was: )

> Steering Delivery Test Cases
> 
>
> Key: TC-48
> URL: https://issues.apache.org/jira/browse/TC-48
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.0.0
>Reporter: Dewayne Richardson
>Priority: Minor
>  Labels: api_steering_internal
>
> Temporarily removed the "t/api/1.2/steering_internal.t" so this will have to 
> be revisited and pulled from 1.8.x after 'psql-rebase' has been merged into 
> 'master'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-55) Multi Delivery Services With Same Domain Name and Different Path Prefixes

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-55:
--
Labels: delivery_service domain_name  (was: )

> Multi Delivery Services With Same Domain Name and Different Path Prefixes
> -
>
> Key: TC-55
> URL: https://issues.apache.org/jira/browse/TC-55
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 1.7.0
>Reporter: Jifeng Yang
>  Labels: delivery_service, domain_name
> Attachments: screenshot-1.png
>
>
> Enhance TC to support:
> Multi Delivery Services With Same Domain Name and Different Path Prefixes
> Details please ref the link:
> https://docs.google.com/document/d/19-TZ6ODla_vdiYqZajbpRiOpLvpbJxil1SvIm44zb-0/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-48) Steering Delivery Test Cases

[Ryan Durfey (JIRA)]

[ 
https://issues.apache.org/jira/browse/TC-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049552#comment-16049552
 ] 

Ryan Durfey commented on TC-48:
---

Is this resolved?

> Steering Delivery Test Cases
> 
>
> Key: TC-48
> URL: https://issues.apache.org/jira/browse/TC-48
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.0.0
>Reporter: Dewayne Richardson
>Priority: Minor
>
> Temporarily removed the "t/api/1.2/steering_internal.t" so this will have to 
> be revisited and pulled from 1.8.x after 'psql-rebase' has been merged into 
> 'master'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-59) Traffic Ops Client should return HTTP body on Error response

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-59:
--
Component/s: Traffic Portal

Is this still valid with the direction to move to Traffic Portal?  Should it 
still be fixed in TO Client or considered for Traffic Portal design?

> Traffic Ops Client should return HTTP body on Error response
> 
>
> Key: TC-59
> URL: https://issues.apache.org/jira/browse/TC-59
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops Client , Traffic Portal
>Reporter: David Neuman
>
> Currently, if the Traffic Ops client gets back an Error response from TO, the 
> calling method is returned a struct containing the StatusCode and Status 
> (https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/client/traffic_ops.go#L180).
>   Sometimes there is useful information in the body of the response as well - 
> such as why an error occured -- so it would be useful to return the body to 
> the calling method as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-60) CDN usage overview API always returns tps=0

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-60:
--
Labels: api_usage  (was: )

> CDN usage overview API always returns tps=0
> ---
>
> Key: TC-60
> URL: https://issues.apache.org/jira/browse/TC-60
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 1.7.0
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: api_usage
>
> /api/1.2/cdns/usage/overview always returns tps=0
> I suspect the problem lies in the usage_overview_tps_query() query
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/Delegate/CdnStatistics.pm#L104



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-64) Experimental SPA application

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-64:
--
Component/s: Traffic Portal
Summary: Experimental SPA application  (was: TO experimental SPA 
application)

> Experimental SPA application
> 
>
> Key: TC-64
> URL: https://issues.apache.org/jira/browse/TC-64
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Ops API, Traffic Portal
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>
> At the 2016 Traffic Control summit, a prototype of a SPA application 
> developed by [~mitchell...@apache.org] using AngularJS was demo'd that works 
> entirely on top of the TO API.
> This issue is a placeholder for any work done to this prototype / 
> experimental UI. The goal is to replicate the functionality of the current 
> MVC TO UI. nothing more, nothing less.
> This will require some additions to the TO API. look for issues regarding 
> each API addition.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-64) TO experimental SPA application

[Ryan Durfey (JIRA)]

[ 
https://issues.apache.org/jira/browse/TC-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049543#comment-16049543
 ] 

Ryan Durfey commented on TC-64:
---

Is this resolved?

> TO experimental SPA application
> ---
>
> Key: TC-64
> URL: https://issues.apache.org/jira/browse/TC-64
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Ops API, Traffic Portal
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>
> At the 2016 Traffic Control summit, a prototype of a SPA application 
> developed by [~mitchell...@apache.org] using AngularJS was demo'd that works 
> entirely on top of the TO API.
> This issue is a placeholder for any work done to this prototype / 
> experimental UI. The goal is to replicate the functionality of the current 
> MVC TO UI. nothing more, nothing less.
> This will require some additions to the TO API. look for issues regarding 
> each API addition.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-71) Remove hardcoded reference to ccr in UI/DeliveryService.pm

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-71:
--
Labels: deliveryservice.pm routing  (was: )

> Remove hardcoded reference to ccr in UI/DeliveryService.pm
> --
>
> Key: TC-71
> URL: https://issues.apache.org/jira/browse/TC-71
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Jeremy Mitchell
>Assignee: Robert Scrimo
>Priority: Minor
>  Labels: deliveryservice.pm, routing
>
> because the value of http.routing.name in applicationContext.xml can be 
> anything (defaults to tr), this needs to be dynamic rather than referencing 
> the hard-coded value of 'ccr'. So my suggestion would be:
> create a global parameter using a database migration file and name the 
> parameter http.routing.name and set the default value to 'tr'. then in the 
> code, fetch the value of http.routing.name and use that on line 147 & 150
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/UI/DeliveryService.pm#L147
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/UI/DeliveryService.pm#L150



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-74) Stop using MIME::Lite to send email

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-74:
--
 Labels: email  (was: )
Summary: Stop using MIME::Lite to send email  (was: TO - Stop using 
MIME::Lite to send email)

> Stop using MIME::Lite to send email
> ---
>
> Key: TC-74
> URL: https://issues.apache.org/jira/browse/TC-74
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: email
>
> Traffic Ops currently uses the MIME::Lite library to send email.
> According to the MIME::Lite documentation:
> MIME::Lite is not recommended by its current maintainer. There are a number 
> of alternatives, like Email::MIME or MIME::Entity and Email::Sender, which 
> you should probably use instead. MIME::Lite continues to accrue weird bug 
> reports, and it is not receiving a large amount of refactoring due to the 
> availability of better alternatives. Please consider using something else.
> Here is a list of bugs logged against MIME::Lite - 
> https://rt.cpan.org/Public/Dist/Display.html?Name=MIME-Lite



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-73) Enhance LDAP implementation to follow referrals

[Ryan Durfey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TC-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-73:
--
 Labels: ldap.conf  (was: )
Summary: Enhance LDAP implementation to follow referrals  (was: TO - 
Enhance LDAP implementation to follow referrals)

> Enhance LDAP implementation to follow referrals
> ---
>
> Key: TC-73
> URL: https://issues.apache.org/jira/browse/TC-73
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: ldap.conf
>
> the ldap.conf file created from postinstall looks like this and is required 
> to support ldap authentication:
> { "host" : "ldap.foo.bar.com", "admin_dn" : "ad...@foo.bar.com", "admin_pass" 
> : "password", "search_base" : "dc=foo,dc=bar,dc=com" }
> this means if you login using ldap credentials, the search is scoped to the 
> foo subdomain. If there are other subdomains in bar (i.e. foo1 and foo2), you 
> may want to increase the scope of the search and change the search_base of 
> your ldap configuration to look like:
> { "host" : "ldap.foo.bar.com", "admin_dn" : "ad...@foo.bar.com", "admin_pass" 
> : "password", "search_base" : "dc=bar,dc=com" }
> however, the current implementation of ldap in traffic ops using Net::LDAP 
> does not support following "referrals".
> Looks like the relevant code is here or around here: 
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/TrafficOps.pm#L393
> This link may offer some more insight into referrals: 
> http://etutorials.org/Server+Administration/ldap+system+administration/Part+II+Application+Integration/Chapter+10.+Net+LDAP+and+Perl/10.5+Advanced+Net+LDAP+Scripting/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)