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

[Zhilin Huang (JIRA)]

[ 
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)

[jira] [Commented] (TC-169) TR download the RGB file continuously when the same RGB file on server

[Zhilin Huang (JIRA)]

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

Zhilin Huang commented on TC-169:
-

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

> TR download the RGB file continuously when the same RGB file on server 
> ---
>
> Key: TC-169
> URL: https://issues.apache.org/jira/browse/TC-169
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Router
>Affects Versions: 1.7.0
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>  Labels: rgb
>
> If the RGB file on server is: 
> 1. completely the same with the RGB file on TR
> 2. last modified time is later than the RGB file on TR
> TR will download the RGB file from server at every polling interval. 
> Expected behavior is that TR should not download the RGB file any longer when 
> the RGB file on server has been downloaded to TR and it was unmodified since 
> then.



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

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

[Zhilin Huang (JIRA)]

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

Zhilin Huang commented on TC-373:
-

No, the PR is still open in the repo.

> 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-187) Update delivery service makes SSL keys invalid

[Zhilin Huang (JIRA)]

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

Zhilin Huang commented on TC-187:
-

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

> Update delivery service makes SSL keys invalid
> --
>
> Key: TC-187
> URL: https://issues.apache.org/jira/browse/TC-187
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>  Labels: ssl, xml-id
>
> Modify xml-id or subdomain in a https delivery service will make existing SSL 
> keys invalid.
> And there is problem to generate keys if using "http and https" together with 
> 1 host_regex, and 1 path_regex.
> BTW, the certificate returned by RESTful API is not consistent with that GUI.



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

Jenkins build is back to normal : incubator-trafficcontrol-rat #76

[Apache Jenkins Server]

See 

Build failed in Jenkins: incubator-trafficcontrol-rat #75

[Apache Jenkins Server]

See 


--
Started by upstream project "incubator-trafficcontrol-master-build" build 
number 76
originally caused by:
 Started by an SCM change
 Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-4 (ubuntu trusty) in workspace 

[incubator-trafficcontrol-rat] $ /bin/bash -xe /tmp/hudson4895866075800654892.sh
+ rm -rf 

 

 '
[operations-center-context] Requesting copy of artifacts matching '**/*.tar.gz' 
from 'Last successful build (either stable or unstable)' of 
incubator-trafficcontrol-master-build
[operations-center-context] Copied 1 artifacts matching '**/*.tar.gz' from 
'Last successful build (either stable or unstable)' of 
incubator-trafficcontrol-master-build:
[operations-center-context]   trafficcontrol-incubating-2.1.0.tar.gz
[incubator-trafficcontrol-rat] $ /bin/bash -xe /tmp/hudson8241735157419995785.sh
+ set -exu
++ ls trafficcontrol-incubating-2.1.0.tar.gz
+ tarball=trafficcontrol-incubating-2.1.0.tar.gz
+ tar xzf trafficcontrol-incubating-2.1.0.tar.gz
++ pwd
++ basename trafficcontrol-incubating-2.1.0.tar.gz .tar.gz
+ 
tcdir=
+ cd 

++ date +%Y
+ grep 'Copyright 2017 The Apache Software Foundation' NOTICE
Copyright 2017 The Apache Software Foundation
+ set +x
Searching for class files:
PASSED: No class files found.
Searching for jar files:
PASSED: No jar files found.
Searching for tar files:
PASSED: No tar files found.
Searching for tgz files:
PASSED: No tgz files found.
Searching for zip files:
PASSED: No zip files found.
+ ratver=apache-rat-0.13-20170427.032418-37.jar
++ mktemp -d
+ ratdir=/tmp/tmp.814DR1Bgh1
+ ratjar=/tmp/tmp.814DR1Bgh1/apache-rat-0.13.SNAPSHOT.jar
+ curl -L -o /tmp/tmp.814DR1Bgh1/apache-rat-0.13.SNAPSHOT.jar 
https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/0.13-SNAPSHOT/apache-rat-0.13-20170427.032418-37.jar
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0  
2 1587k2 409600 0  69280  0  0:00:23 --:--:--  0:00:23 69189100 
1587k  100 1587k0 0  1691k  0 --:--:-- --:--:-- --:--:-- 1690k
+ curl -L -o /tmp/tmp.814DR1Bgh1/apache-rat-0.13.SNAPSHOT.jar.sha1 
https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/0.13-SNAPSHOT/apache-rat-0.13-20170427.032418-37.jar.sha1
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
010040  100400 0 99  0 --:--:-- --:--:-- --:--:--   100
++ sha1sum /tmp/tmp.814DR1Bgh1/apache-rat-0.13.SNAPSHOT.jar
++ awk '{print $1}'
++ cat /tmp/tmp.814DR1Bgh1/apache-rat-0.13.SNAPSHOT.jar.sha1
+ [[ ac5cfd859902d5c858baed8dbcf91c014ce9ae23 == 
ac5cfd859902d5c858baed8dbcf91c014ce9ae23 ]]
++ pwd
++ pwd
+ java -jar /tmp/tmp.814DR1Bgh1/apache-rat-0.13.SNAPSHOT.jar -E 

 -d 

+ rm -rf /tmp/tmp.814DR1Bgh1
++ perl -lne 'print $1 if /\(\d+\) Unknown Licenses/' ratreport.txt
+ unknown=
+ [[ '' != 0 ]]
+ echo ' Unknown Licenses'
 Unknown Licenses
+ perl -lne 'print if /Files with unapproved licenses:/ .. /^\*\*\*/' 
ratreport.txt
+ sed s:::
+ exit 1
Build step 'Execute shell' marked build as failure
Archiving artifacts
No artifacts from incubator-trafficcontrol-rat #23 to compare, so performing 
full copy of artifacts

[GitHub] incubator-trafficcontrol pull request #679: [Backport] updates TO install do...

[dangogh]

Github user dangogh closed the pull request at:

https://github.com/apache/incubator-trafficcontrol/pull/679


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[Eric Friedrich (JIRA)]

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

Eric Friedrich closed TC-90.


> 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] [Resolved] (TC-90) TR should check for closest cache group because using Maxmind Geolocation

[Eric Friedrich (JIRA)]

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

Eric Friedrich resolved TC-90.
--
Resolution: Fixed

> 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

[Eric Friedrich (JIRA)]

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

Eric Friedrich commented on TC-90:
--

yeah, i'll close it

> 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-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)

Build failed in Jenkins: incubator-trafficcontrol-2.0.x-rat #4

[Apache Jenkins Server]

See 


--
Started by upstream project "incubator-trafficcontrol-2.0.x-build" build number 
12
originally caused by:
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
 Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-4 (ubuntu trusty) in workspace 

[incubator-trafficcontrol-2.0.x-rat] $ /bin/bash -xe 
/tmp/hudson4866559042987778549.sh
+ rm -rf 
' 
'
[operations-center-context] Requesting copy of artifacts matching '**/*.tar.gz' 
from 'Last successful build (either stable or unstable)' of 
incubator-trafficcontrol-2.0.x-build
[operations-center-context] Copied 1 artifacts matching '**/*.tar.gz' from 
'Last successful build (either stable or unstable)' of 
incubator-trafficcontrol-2.0.x-build:
[operations-center-context]   trafficcontrol-incubating-2.0.0.tar.gz
[incubator-trafficcontrol-2.0.x-rat] $ /bin/bash -xe 
/tmp/hudson9071880834864450060.sh
+ set -exu
++ ls trafficcontrol-incubating-2.0.0.tar.gz
+ tarball=trafficcontrol-incubating-2.0.0.tar.gz
+ tar xzf trafficcontrol-incubating-2.0.0.tar.gz
++ pwd
++ basename trafficcontrol-incubating-2.0.0.tar.gz .tar.gz
+ 
tcdir=
+ cd 

++ date +%Y
+ grep 'Copyright 2017 The Apache Software Foundation' NOTICE
Copyright 2017 The Apache Software Foundation
+ set +x
Searching for class files:
PASSED: No class files found.
Searching for jar files:
PASSED: No jar files found.
Searching for tar files:
PASSED: No tar files found.
Searching for tgz files:
PASSED: No tgz files found.
Searching for zip files:
PASSED: No zip files found.
+ ratver=apache-rat-0.13-20170427.032418-37.jar
++ mktemp -d
+ ratdir=/tmp/tmp.AVSwEFwkBO
+ ratjar=/tmp/tmp.AVSwEFwkBO/apache-rat-0.13.SNAPSHOT.jar
+ curl -L -o /tmp/tmp.AVSwEFwkBO/apache-rat-0.13.SNAPSHOT.jar 
https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/0.13-SNAPSHOT/apache-rat-0.13-20170427.032418-37.jar
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0  
0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0100 
1587k  100 1587k0 0  1714k  0 --:--:-- --:--:-- --:--:-- 1713k
+ curl -L -o /tmp/tmp.AVSwEFwkBO/apache-rat-0.13.SNAPSHOT.jar.sha1 
https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/0.13-SNAPSHOT/apache-rat-0.13-20170427.032418-37.jar.sha1
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0  
0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0100 
   40  100400 0101  0 --:--:-- --:--:-- --:--:--   101
++ awk '{print $1}'
++ sha1sum /tmp/tmp.AVSwEFwkBO/apache-rat-0.13.SNAPSHOT.jar
++ cat /tmp/tmp.AVSwEFwkBO/apache-rat-0.13.SNAPSHOT.jar.sha1
+ [[ ac5cfd859902d5c858baed8dbcf91c014ce9ae23 == 
ac5cfd859902d5c858baed8dbcf91c014ce9ae23 ]]
++ pwd
++ pwd
+ java -jar /tmp/tmp.AVSwEFwkBO/apache-rat-0.13.SNAPSHOT.jar -E 

 -d 

+ rm -rf /tmp/tmp.AVSwEFwkBO
++ perl -lne 'print if /\(\d+\) Unknown Licenses/' ratreport.txt
+ unknown=
+ [[ '' != 0 ]]
+ echo ' Unknown Licenses'
 Unknown Licenses
+ perl -lne 'print if /Files with unapproved licenses:/ .. /^\*\*\*/' 
ratreport.txt
+ sed s:::
Files with unapproved licenses:

  trafficcontrol-incubating-2.0.0/traffic_ops/install/bin/todb_bootstrap.sh
  trafficcontrol-incubating-2.0.0/traffic_ops_db/pg-migration/runwaiter.sh

*
+ exit 1
Build step 'Execute shell' marked build as failure
Archiving artifacts
No prior successful build to compare, so performing full copy of artifacts

[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)

Build failed in Jenkins: incubator-trafficcontrol-rat #74

[Apache Jenkins Server]

See 


--
Started by upstream project "incubator-trafficcontrol-master-build" build 
number 76
originally caused by:
 Started by an SCM change
 Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-2 (ubuntu trusty) in workspace 

[incubator-trafficcontrol-rat] $ /bin/bash -xe /tmp/hudson7418686610563646209.sh
+ rm -rf ' 
'
[operations-center-context] Requesting copy of artifacts matching '**/*.tar.gz' 
from 'Last successful build (either stable or unstable)' of 
incubator-trafficcontrol-master-build
[operations-center-context] Copied 1 artifacts matching '**/*.tar.gz' from 
'Last successful build (either stable or unstable)' of 
incubator-trafficcontrol-master-build:
[operations-center-context]   trafficcontrol-incubating-2.1.0.tar.gz
[incubator-trafficcontrol-rat] $ /bin/bash -xe /tmp/hudson168015875390646956.sh
+ set -exu
++ ls trafficcontrol-incubating-2.1.0.tar.gz
+ tarball=trafficcontrol-incubating-2.1.0.tar.gz
+ tar xzf trafficcontrol-incubating-2.1.0.tar.gz
++ pwd
++ basename trafficcontrol-incubating-2.1.0.tar.gz .tar.gz
+ 
tcdir=
+ cd 

++ date +%Y
+ grep 'Copyright 2017 The Apache Software Foundation' NOTICE
Copyright 2017 The Apache Software Foundation
+ set +x
Searching for class files:
PASSED: No class files found.
Searching for jar files:
PASSED: No jar files found.
Searching for tar files:
PASSED: No tar files found.
Searching for tgz files:
PASSED: No tgz files found.
Searching for zip files:
PASSED: No zip files found.
+ ratver=apache-rat-0.13-20170427.032418-37.jar
++ mktemp -d
+ ratdir=/tmp/tmp.lph0AvV1h9
+ ratjar=/tmp/tmp.lph0AvV1h9/apache-rat-0.13.SNAPSHOT.jar
+ curl -L -o /tmp/tmp.lph0AvV1h9/apache-rat-0.13.SNAPSHOT.jar 
https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/0.13-SNAPSHOT/apache-rat-0.13-20170427.032418-37.jar
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0 
52 1587k   52  832k0 0   950k  0  0:00:01 --:--:--  0:00:01  
949k100 1587k  100 1587k0 0  1699k  0 --:--:-- --:--:-- --:--:-- 
1699k
+ curl -L -o /tmp/tmp.lph0AvV1h9/apache-rat-0.13.SNAPSHOT.jar.sha1 
https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/0.13-SNAPSHOT/apache-rat-0.13-20170427.032418-37.jar.sha1
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
010040  100400 0 99  0 --:--:-- --:--:-- --:--:--99
++ sha1sum /tmp/tmp.lph0AvV1h9/apache-rat-0.13.SNAPSHOT.jar
++ awk '{print $1}'
++ cat /tmp/tmp.lph0AvV1h9/apache-rat-0.13.SNAPSHOT.jar.sha1
+ [[ ac5cfd859902d5c858baed8dbcf91c014ce9ae23 == 
ac5cfd859902d5c858baed8dbcf91c014ce9ae23 ]]
++ pwd
++ pwd
+ java -jar /tmp/tmp.lph0AvV1h9/apache-rat-0.13.SNAPSHOT.jar -E 

 -d 

+ rm -rf /tmp/tmp.lph0AvV1h9
++ perl -lne 'print if /\(\d+\) Unknown Licenses/' ratreport.txt
+ unknown=
+ [[ '' != 0 ]]
+ echo ' Unknown Licenses'
 Unknown Licenses
+ perl -lne 'print if /Files with unapproved licenses:/ .. /^\*\*\*/' 
ratreport.txt
+ sed s:::
+ exit 1
Build step 'Execute shell' marked build as failure
Archiving artifacts
No artifacts from incubator-trafficcontrol-rat #23 to compare, so performing 
full copy of artifacts

[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)

[GitHub] incubator-trafficcontrol pull request #679: [Backport] updates TO install do...

[dangogh]

GitHub user dangogh opened a pull request:

https://github.com/apache/incubator-trafficcontrol/pull/679

[Backport] updates TO install docs; adds build instructions to docs

@limited :TO install instructions from @knutsel,  build instructions 
from @dangogh

Also removes experimental files with potential license issues.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dangogh/incubator-trafficcontrol 2.0-docs

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafficcontrol/pull/679.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #679


commit 5f87aba03188dfe241cb6d979eb0f8e4f0416236
Author: Jan van Doorn 
Date:   2017-06-11T16:04:21Z

Updated TO install docs, works with master 6/11/2017

(cherry picked from commit 2545a06a519c518df7c52aee8c70825272be5c55)

commit 921a2c7c631ec949029192098b96fde9fb65a83f
Author: Jan van Doorn 
Date:   2017-06-11T20:58:30Z

Change doc version to 2.0.0

commit 3ba99039fdc934572a4e1c2ba6cf946384f4af29
Author: Jan van Doorn 
Date:   2017-06-11T21:00:34Z

Change pngmath to imgmath to clear warning.

(cherry picked from commit b56846ea54df6cf4c6e3be249a2fb5869674cf7b)

commit cc294ec85092034db5b34f6532b46e4bd70b1a70
Author: Jan van Doorn 
Date:   2017-06-12T18:45:34Z

enable pg autostart

(cherry picked from commit 3bc4b79685e6acbca0bac55901a02fdafdb654f1)

commit 68dd88e31ea3dd285d6d81c67c37ed12b8576df4
Author: Dan Kirkwood 
Date:   2017-06-13T19:38:39Z

add building doc to development page

(cherry picked from commit 1c84235d94831b215e94c32bffebd7189ea2c285)

commit d4ea50156e40b9de1c7a54565b015e4ccf70a6c9
Author: Dan Kirkwood 
Date:   2017-06-13T21:58:09Z

more explicit instructions + alternate instructions using docker-compose

(cherry picked from commit 3b93cb610dde5519268bec84afeab46fb0ac25c6)

commit ae49ea39e3592a97db5ba9881032ce329a4f6c40
Author: Dan Kirkwood 
Date:   2017-06-13T21:59:34Z

fix a few nits; point to building page for rpm

(cherry picked from commit fd44a78835df48bbe51442f0d3d5e0b2a28a1279)

commit a7f689e4924140596d5e1eb35c7cb39d7516f8d6
Author: Dan Kirkwood 
Date:   2017-06-13T22:02:21Z

build instructions moved to doc

(cherry picked from commit a431b5d88950f6f9b85f0dd70516ac92f1d9fe6e)

commit 82d3da64ef2b5be24f5adfa40e25a1a783e753e7
Author: Dan Kirkwood 
Date:   2017-06-14T18:36:21Z

add missing copyright

(cherry picked from commit 272abdce1424d1991395307a845195ab4a5bf78a)

commit f6c8d6f462de6c2f094d1d6409ba9ae2338b982b
Author: Dan Kirkwood 
Date:   2017-06-14T18:40:47Z

remove files with unknown licenses -- if these are needed, need to resolve 
license issue before re-adding

(cherry picked from commit f243c67d0f60b69ad58707cfae4b11ad3e3ee624)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[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)

[GitHub] incubator-trafficcontrol pull request #678: resolve final license issues

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-trafficcontrol/pull/678


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[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)

[jira] [Updated] (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 updated TC-82:
--
Labels: api_endpoints  (was: )

> 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: 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] [Commented] (TC-98) failed to delete sslkeys by TrafficOps API

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-98:
---

Is this resolved?

> failed to delete sslkeys by TrafficOps  API 
> 
>
> Key: TC-98
> URL: https://issues.apache.org/jira/browse/TC-98
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API, Traffic Vault
>Affects Versions: 1.7.0
>Reporter: pengywu
>Priority: Minor
>  Labels: api_deliveryservices
>
> 1. I tried to  delete SSL keys by API for Delivery Services: https001 as 
> follows:
> /api/1.1/deliveryservices/xmlId/https001/sslkeys/delete.json
> 2.The result  was failure, the sslkey  for https001 stilled  in Traffic Vault.



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

[jira] [Updated] (TC-98) failed to delete sslkeys by TrafficOps API

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-98:
--
Labels: api_deliveryservices  (was: )

> failed to delete sslkeys by TrafficOps  API 
> 
>
> Key: TC-98
> URL: https://issues.apache.org/jira/browse/TC-98
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API, Traffic Vault
>Affects Versions: 1.7.0
>Reporter: pengywu
>Priority: Minor
>  Labels: api_deliveryservices
>
> 1. I tried to  delete SSL keys by API for Delivery Services: https001 as 
> follows:
> /api/1.1/deliveryservices/xmlId/https001/sslkeys/delete.json
> 2.The result  was failure, the sslkey  for https001 stilled  in Traffic Vault.



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

[jira] [Commented] (TC-99) api/{version}/cdns/:cdn_name/health returns the health of all cdns

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-99:
---

Is this resolved?


> api/{version}/cdns/:cdn_name/health returns the health of all cdns
> --
>
> Key: TC-99
> URL: https://issues.apache.org/jira/browse/TC-99
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: api_cdns
>
> There are 2 routes that fetch the health of cachegroups for a cdn:
> (health is defined in this context as the number of offline/online servers 
> for each cachegroup)
> /api/$version/cdns/health
> /api/$version/cdns/:name/health
> ^^ you would think the 2nd one would fetch the health of the cachegroups for 
> the specified cdn but it does not.



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

[jira] [Updated] (TC-99) api/{version}/cdns/:cdn_name/health returns the health of all cdns

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-99:
--
Labels: api_cdns  (was: )

> api/{version}/cdns/:cdn_name/health returns the health of all cdns
> --
>
> Key: TC-99
> URL: https://issues.apache.org/jira/browse/TC-99
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: api_cdns
>
> There are 2 routes that fetch the health of cachegroups for a cdn:
> (health is defined in this context as the number of offline/online servers 
> for each cachegroup)
> /api/$version/cdns/health
> /api/$version/cdns/:name/health
> ^^ you would think the 2nd one would fetch the health of the cachegroups for 
> the specified cdn but it does not.



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

[jira] [Updated] (TC-100) DELETE api/version/regions/:id should ensure no phys locs are in the region

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-100:
---
Labels: api_regions  (was: )

> DELETE api/version/regions/:id should ensure no phys locs are in the region
> ---
>
> Key: TC-100
> URL: https://issues.apache.org/jira/browse/TC-100
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: api_regions
>
> Currently, you can attempt to delete a region that is employed by a phys 
> location which results in a database FK constraint error.
> DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute 
> failed: ERROR:  update or delete on table region violates foreign 
> key constraint fk_phys_location_region on table 
> phys_location
> DETAIL:  Key (id)=(1) is still referenced from table 
> phys_location. [for Statement DELETE FROM region WHERE ( id 
> = ? ) with ParamValues: 1=1] at 
> /opt/traffic_ops/app/lib/API/Region.pm line 243
> the api needs to ensure that no phys locs use the region before attempting to 
> delete the region.



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

[jira] [Updated] (TC-111) domain_name of CDN should be in the CDN table, not in the "CCR profile".

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-111:
---
Labels: table_ccr_profile table_cdn  (was: )

> domain_name of CDN should be in the CDN table, not in the "CCR profile".
> 
>
> Key: TC-111
> URL: https://issues.apache.org/jira/browse/TC-111
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Jan van Doorn
>Assignee: Jan van Doorn
>Priority: Minor
>  Labels: table_ccr_profile, table_cdn
>




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

[jira] [Updated] (TC-115) ATS sometimes does not reload the config while receiving a "traffic_line -x"

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-115:
---
Labels: traffic_line-x  (was: )

> ATS sometimes does not reload the config while receiving a "traffic_line -x"
> 
>
> Key: TC-115
> URL: https://issues.apache.org/jira/browse/TC-115
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops ORT
>Reporter: John Shen
>Assignee: John Shen
>Priority: Minor
>  Labels: traffic_line-x
>
> If the owner of a config file (e.g. ssl_multicert.config) is not ats.ats, ATS 
> does not reload the config while receiving a "traffic_line -x".



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

[jira] [Updated] (TC-118) Traffic Ops should get it's name from some confioguration when generating CrConfig

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-118:
---
Labels: configuration crconfig  (was: )

> Traffic Ops should get it's name from some confioguration when generating 
> CrConfig
> --
>
> Key: TC-118
> URL: https://issues.apache.org/jira/browse/TC-118
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 1.7.0
>Reporter: Oren Shemesh
>Priority: Minor
>  Labels: configuration, crconfig
>
> The code that generates the CrConfig has a problem when creating the "stat" 
> section.
> It fills values for that section, such as "tm_host", based on the HTTP 
> headers found in the request that triggered the CrConfig snapshot:
> Here is a snippet from traffic_ops/app/lib/UI/Topology.pm:
> $data_obj->{'stats'}->{'tm_path'}= $self->req->url->path->{'path'};
> $data_obj->{'stats'}->{'tm_host'}= $self->req->headers->host;
> I find this to be a problem for two reasons:
> This code assumes that it is being run from the context of an HTTP 
> transaction, which to me sounds like contaminating the logic of actually 
> creating the CrConfig with details from the upper layer which currently uses 
> this logic. 
> For example, if one would want to run this code from a different path (Maybe 
> in a unit test), it would be a problem.
> If the traffic ops is accessed through a NAT, then the host name known to the 
> HTTP client issuing the 'Snapshot CrConfig' request is not necessarily the 
> same as the traffic ops host name known to the other components of the 
> system, e.g. the traffic router that uses this information.
> (This is how I found out about this problem - we are experimenting with 
> deploying TC in the cloud (Amazon EC2) and the host name visible to the 
> outside world is not the same as the host names used internally)
> I believe that tm_host should come from the database (Currently there is no 
> entry from the traffic ops itself, but such an entry can be created for this 
> purpose), or from cdn.conf.



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

[jira] [Updated] (TC-121) Parametrized traffic-server configuration

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-121:
---
Labels: configuration  (was: )
Issue Type: New Feature  (was: Improvement)

> Parametrized traffic-server configuration
> -
>
> Key: TC-121
> URL: https://issues.apache.org/jira/browse/TC-121
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops
>Reporter: Nir Sopher
>Priority: Minor
>  Labels: configuration
>
> We would like to allow an individual traffic-server configuration, dervied 
> from its profile as well as its specific configuration.
> For example, set the traffic-server to listen the configured IP by setting  
> proxy-local-incoming-ip-to-bind value.
> In order to do so, variables should be embedded within profile variables 
> values.
> For example:  __CACHE_IPV4__ and  __CACHE_IPV6__ 
> Future variables to discuss: http/s ports, hostname, domain



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

[GitHub] incubator-trafficcontrol pull request #678: resolve final license issues

[dangogh]

GitHub user dangogh opened a pull request:

https://github.com/apache/incubator-trafficcontrol/pull/678

resolve final license issues

Added license to new `building.rst` file.

Removed files in "experimental" that still don't have license resolution in 
place to finally get the rat tool to pass.

If they are needed,  the license issue needs to be resolved prior to 
merging in.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dangogh/incubator-trafficcontrol 
remove-licenses

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafficcontrol/pull/678.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #678


commit 294fb2b80e625d16fd1b694a89e9f7d70ed664d0
Author: Dan Kirkwood 
Date:   2017-06-14T18:36:21Z

add missing copyright

commit 7ec6a78f9f2fc4744e2189f7f52529a2455d1385
Author: Dan Kirkwood 
Date:   2017-06-14T18:40:47Z

remove files with unknown licenses -- if these are needed, need to resolve 
license issue before re-adding




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TC-123) UI route (/healthdatadeliveryservice) is broken as no related html template exists

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-123:
---
Component/s: Traffic Ops API

> UI route (/healthdatadeliveryservice) is broken as no related html template 
> exists
> --
>
> Key: TC-123
> URL: https://issues.apache.org/jira/browse/TC-123
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.0.0
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: api_healthdatadeliveryservice
>
> /healthdatadeliveryservice returns a 404 as no related html template exists 
> for this route. My guess is this route can be deleted entirely but some 
> research is probably needed.



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

[jira] [Updated] (TC-123) UI route (/healthdatadeliveryservice) is broken as no related html template exists

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-123:
---
 Labels: api_healthdatadeliveryservice  (was: )
Summary: UI route (/healthdatadeliveryservice) is broken as no related html 
template exists  (was: TO UI route (/healthdatadeliveryservice) is broken as no 
related html template exists)

> UI route (/healthdatadeliveryservice) is broken as no related html template 
> exists
> --
>
> Key: TC-123
> URL: https://issues.apache.org/jira/browse/TC-123
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: api_healthdatadeliveryservice
>
> /healthdatadeliveryservice returns a 404 as no related html template exists 
> for this route. My guess is this route can be deleted entirely but some 
> research is probably needed.



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

[jira] [Updated] (TC-148) GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns pointer to Hash

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-148:
---
Labels: api_deliveryservices  (was: )

> GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns pointer to Hash
> --
>
> Key: TC-148
> URL: https://issues.apache.org/jira/browse/TC-148
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: api_deliveryservices
>
> GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns, for example:
> {
> response: "HTTP::Response=HASH(0x6f9f018)"
> }
> instead of the actual json hash/object.



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

[jira] [Updated] (TC-149) GET api/1.2/deliveryservices/hostname/:hostname/sslkeys returns 400

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-149:
---
Labels: api_deliveryservices  (was: )

> GET api/1.2/deliveryservices/hostname/:hostname/sslkeys returns 400
> ---
>
> Key: TC-149
> URL: https://issues.apache.org/jira/browse/TC-149
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: api_deliveryservices
>
> GET api/1.2/deliveryservices/hostname/:hostname/sslkeys returns 400 even 
> though it can reach the Riak servers.



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

[jira] [Updated] (TC-150) generateCert script not echoing prompts from openssl

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-150:
---
Labels: ssl  (was: )

> generateCert script not echoing prompts from openssl
> 
>
> Key: TC-150
> URL: https://issues.apache.org/jira/browse/TC-150
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0, 2.1.0
> Environment: New install on Centos 7
>Reporter: Dan Kirkwood
>Priority: Minor
>  Labels: ssl
> Fix For: 2.0.0, 2.1.0
>
>
> using the script to generate certs,  the initial prompts are shown,  but when 
> it gets to asking for city, state, organization, etc,  the prompt isn't shown 
> and appears to hang.  Hit  9 times, and it shows the next prompt 
> after that portion..
> This should be trivial to fix...Script is 
> traffic_ops/install/bin/generateCert



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

[jira] [Updated] (TC-151) Delivery Service XML IDs should be limited to lower-case letters

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-151:
---
Labels: delivery_service xml-id  (was: )

> Delivery Service XML IDs should be limited to lower-case letters
> 
>
> Key: TC-151
> URL: https://issues.apache.org/jira/browse/TC-151
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 1.7.0
>Reporter: Oren Shemesh
>Priority: Minor
>  Labels: delivery_service, xml-id
>
> The DNS system is case-insensitive. Since a delivery service XML ID is used 
> as part of the FQDN of the cache being redirected to, two different DSs 
> cannot differ only by case.
> This leads to the conclusion that it is best if we limit the XML IDs of 
> delivery services to be lower-case only.
> This would achieve the following:
> 1. Make domain names used by TC 'conventional' (i.e. lower-case only)
> 2. Remove the possibility of a case-conflict between DSs
> 3. Currently, Traffic Router does not behave correctly when a DS XML ID 
> contains upper case letters. Limiting to lower-case would prevent the need to 
> fix this :-)
> Current problems with TR behaviour, when an XML ID contains opper-case letter 
> are:
> 1. The TR sends a redirect to a host FQDN which contains a lower-case version 
> of the DS XML ID
> 2. The TR does not resolve the lower-case version of the host FQDN.
> Here is an example to demo current bug in TR. DS XML ID is opencachehub-DT, 
> TR redirects to opencachehub-dt, and then refused to resolve the cache name 
> using this DS (a lot of irrelevant data was removed fro this text):
> $ curl -L -s -D - 
> http://tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com/video01.mp4 -v
> * Connected to tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com 
> (54.244.152.242) port 80 (#0)
> > GET /video01.mp4 HTTP/1.1
> > Host: tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com
> > Accept: */*
> > 
> < HTTP/1.1 302 Moved Temporarily
> < Location: 
> http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4
> < Content-Length: 0
> < 
> * Connection #0 to host tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com left 
> intact
> * Issue another request to this URL: 
> 'http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4'
> * getaddrinfo(3) failed for 
> p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com:80
> * Couldn't resolve host 
> 'p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com'



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

[jira] [Updated] (TC-177) admin.pl should use uri form to connect to postgresql utilities

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-177:
---
Labels: admin.pl postgresql  (was: )

> admin.pl should use uri form to connect to postgresql utilities
> ---
>
> Key: TC-177
> URL: https://issues.apache.org/jira/browse/TC-177
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0, 2.1.0
>Reporter: Dan Kirkwood
>  Labels: admin.pl, postgresql
> Fix For: 2.1.0
>
>
> `admin.pl` uses command line options on each postgres utility command to 
> connect to the db.   This suffers from the same issue we had with pg_dump 
> (see [TC-122]).   The same uri form used for that fix should be used here as 
> well.
> This should be considered for inclusion in 2.0.x..



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

[jira] [Commented] (TC-187) Update delivery service makes SSL keys invalid

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-187:


Just following up, has this been resolved?

> Update delivery service makes SSL keys invalid
> --
>
> Key: TC-187
> URL: https://issues.apache.org/jira/browse/TC-187
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>  Labels: ssl, xml-id
>
> Modify xml-id or subdomain in a https delivery service will make existing SSL 
> keys invalid.
> And there is problem to generate keys if using "http and https" together with 
> 1 host_regex, and 1 path_regex.
> BTW, the certificate returned by RESTful API is not consistent with that GUI.



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

[jira] [Updated] (TC-187) Update delivery service makes SSL keys invalid

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-187:
---
Labels: ssl xml-id  (was: SSL xml-id)

> Update delivery service makes SSL keys invalid
> --
>
> Key: TC-187
> URL: https://issues.apache.org/jira/browse/TC-187
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>  Labels: ssl, xml-id
>
> Modify xml-id or subdomain in a https delivery service will make existing SSL 
> keys invalid.
> And there is problem to generate keys if using "http and https" together with 
> 1 host_regex, and 1 path_regex.
> BTW, the certificate returned by RESTful API is not consistent with that GUI.



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

[jira] [Updated] (TC-188) postinstall -r option should be removed

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-188:
---
Labels: postinstall  (was: )

> postinstall -r option should be removed
> ---
>
> Key: TC-188
> URL: https://issues.apache.org/jira/browse/TC-188
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 1.8.0, 2.0.0, 2.1.0
>Reporter: Peter Ryder
>Priority: Minor
>  Labels: postinstall
> Fix For: 2.1.0
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> With the changes to postinstall, a -r option was introduced to remove a 
> hidden file on the system which determined when to reconfigure the database. 
> Since postinstall is only run during initial installs, it only makes sense to 
> always run in reconfigure mode. If postinstall is run a second time, it will 
> look for files it creates on the system and will warn the user before 
> continuing that their database will be recreated.



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

[jira] [Updated] (TC-191) Steering DS API should use standard response codes as defined in API guidelines

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-191:
---
Labels: steering  (was: )

> Steering DS API should use standard response codes as defined in API 
> guidelines
> ---
>
> Key: TC-191
> URL: https://issues.apache.org/jira/browse/TC-191
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>  Labels: steering
> Fix For: 2.1.0
>
>
> To keep the API consistent, API guidelines have been documented here: 
> https://cwiki.apache.org/confluence/display/TC/API+Guidelines
> See "Response Codes" section. Also, there are helper functions in 
> Utils/Helper.pm to return error response codes along with a message.
> By keeping response codes consistent, it makes it easier to consume the api 
> and respond to error scenarios.



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

[jira] [Updated] (TC-212) Configurable Dashboards in Portal

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-212:
---
Summary: Configurable Dashboards in Portal  (was: Portal - Configurable 
Dashboards)

> Configurable Dashboards in Portal
> -
>
> Key: TC-212
> URL: https://issues.apache.org/jira/browse/TC-212
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Portal
>Reporter: Ashish Timilsina
>Assignee: Jeremy Mitchell
>  Labels: chart, portal, self_service
>
> Create a framework in the CDN Portal so that users have a base set of 
> dashboards that they inherit, and can then create new dashboards based on any 
> service data available to them.
> *Allow users to CRUD dashboards.
> *Allow users to save these dashboards.
> *Allow users to share dashboards they have created with other users so they 
> can save to their account.
> The vision is something along the lines of what Kibana or Grafana already do. 
> May require some query language to be used to create the dashboard.



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