[jira] [Commented] (TC-423) TPv2 - add the ability to copy profiles

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-423:
---

Github user asfgit closed the pull request at:

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


> TPv2 - add the ability to copy profiles
> ---
>
> Key: TC-423
> URL: https://issues.apache.org/jira/browse/TC-423
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Portal
>Reporter: Jeremy Mitchell
>Priority: Minor
>
> In order to achieve feature parity with the existing TO UI, the ability to 
> copy profiles needs to be added to TP. This involves making a new profile 
> where you can define the name, description, cdn and type of the profile but 
> use the parameters of an existing profile.



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

[GitHub] incubator-trafficcontrol pull request #784: [TC-423] - adds clone profile to...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] incubator-trafficcontrol issue #315: [TC-169] update last modified time if f...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/42/



---
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] [Commented] (TC-169) TR download the RGB file continuously when the same RGB file on server

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-169:
---

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/42/



> 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-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=16122742#comment-16122742
 ] 

Zhilin Huang commented on TC-169:
-

[~hbeatty] rebased the PR. no conflicts now.

> 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-505) LDAP only users are greeted with a 404 for all UI / API routes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-505:
---

Github user asfgit closed the pull request at:

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


> LDAP only users are greeted with a 404 for all UI / API routes
> --
>
> Key: TC-505
> URL: https://issues.apache.org/jira/browse/TC-505
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Critical
> Fix For: 2.1.0
>
>
> This is because not_ldap => 1 was added to all routes via this PR:
> https://github.com/apache/incubator-trafficcontrol/pull/627
> which results in a 404 for all UI / API routes if you don't have a user entry 
> in the tm_user table.
> Rather than 404, if you login as ldap-only, you should get a 403 (forbidden) 
> with a nice message about what you should do.



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

[GitHub] incubator-trafficcontrol pull request #793: [TC-505] - throws 403 (rather th...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Commented] (TC-407) Cannot update a steering type delivery service via API

[Jeremy Mitchell (JIRA)]

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

Jeremy Mitchell commented on TC-407:


This code is supposed to skip the org server requirement check if type is 
*steering* or any_map

https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Deliveryservice.pm#L1371

can you ensure that the type of DS you are trying to update is truly of type 
steering? I guess that would mean checking the typeId that is sent in with the 
request and ensure that it lines up with a steering DS. 

Also, I tried updating a STEERING ds via the api in 2.1.x branch and it seems 
to work fine.

> Cannot update a steering type delivery service via API
> --
>
> Key: TC-407
> URL: https://issues.apache.org/jira/browse/TC-407
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Joseph Pappano
>Assignee: Jeremy Mitchell
>
> The API to update a delivery service requires an origin server FQDN. Steering 
> type delivery services to not have one and the api fails with the following 
> error.
> {code}
> {u'alerts': [{u'level': u'error', u'text': u'orgServerFqdn is required'}]}
> {code}



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

[jira] [Created] (TC-509) TO postinstall set default number of secrets to 1

[Dan Kirkwood (JIRA)]

Dan Kirkwood created TC-509:
---

 Summary: TO postinstall set default number of secrets to 1
 Key: TC-509
 URL: https://issues.apache.org/jira/browse/TC-509
 Project: Traffic Control
  Issue Type: Improvement
  Components: Traffic Ops
Affects Versions: 2.1.0, 2.0.0
Reporter: Dan Kirkwood
Priority: Trivial
 Fix For: 2.2.0


postinstall for traffic_ops has default number of secrets to keep as 10.

really no need to keep more than 2,  and default should be only 1.  The list is 
so if you create a new secret, any outstanding authentication cookies don't 
immediately get invalidated.   So, the process should be to create a new 
secret,  wait until max expiration has passed (during which any new cookies are 
created using the new secret),  then remove the old secret.

Old secrets should not be kept any longer than that



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

[jira] [Assigned] (TC-407) Cannot update a steering type delivery service via API

[Jeremy Mitchell (JIRA)]

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

Jeremy Mitchell reassigned TC-407:
--

Assignee: Jeremy Mitchell

> Cannot update a steering type delivery service via API
> --
>
> Key: TC-407
> URL: https://issues.apache.org/jira/browse/TC-407
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Joseph Pappano
>Assignee: Jeremy Mitchell
>
> The API to update a delivery service requires an origin server FQDN. Steering 
> type delivery services to not have one and the api fails with the following 
> error.
> {code}
> {u'alerts': [{u'level': u'error', u'text': u'orgServerFqdn is required'}]}
> {code}



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

[jira] [Commented] (TC-490) mso.qstring_handling parameter is checked but not documented

[Jeremy Mitchell (JIRA)]

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

Jeremy Mitchell commented on TC-490:


I thought but you'd have to ask [~dg4prez] we were moving away from these UI 
config file routes to the API config file routes - 
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Configs/ApacheTrafficServer.pm

so be sure that if any changes are made in UI/ConfigFiles.pm, they are also 
made in ApacheTrafficServer.pm

> mso.qstring_handling parameter is checked but not documented
> 
>
> Key: TC-490
> URL: https://issues.apache.org/jira/browse/TC-490
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Matt Mills
>Priority: Blocker
>
> mso.qstring_handling not listed in docs, seems to be defined elsewhere as 
> psel.qstring_handling
>but MID parent selection code checks if mso.qstring_handling is not defined
> {code}
>my $qsh= 
> $ds->{'param'}->{'parent.config'}->{'mso.qstring_handling'};
>my $parent_qstring = "ignore"; 
>  # default is ignore, unless for alg consistent_hash
>if ( !defined($qsh) && $mso_algorithm eq 'consistent_hash' && 
> $ds->{qstring_ignore} == 0 ) {
>   $parent_qstring = 'consider';
>}
> {code}
> The parameter is unlikely to ever exist, since it's not documented anywhere, 
> but either way either the code should be corrected or the documentation 
> should be.



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

[jira] [Updated] (TC-500) Creating/Updating a Delivery Service via API has length constraint on displayName of 48, but no such constraint in UI code

[Robert Scrimo (JIRA)]

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

Robert Scrimo updated TC-500:
-
Priority: Minor  (was: Major)

> Creating/Updating a Delivery Service via API has length constraint on 
> displayName of 48, but no such constraint in UI code
> --
>
> Key: TC-500
> URL: https://issues.apache.org/jira/browse/TC-500
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Robert Scrimo
>Priority: Minor
>
> Creating/Updating a Delivery Service via API code has length constraint on 
> `displayName` of 48, but there is no such constraint in the UI code so any 
> user can update the value to more than 48 characters.  The Database field is 
> Text which is described as "variable unlimited length" in the Postgres 
> documentation.  However, the value may be limited by the GUI field if such a 
> constraint exists.
> NOTE:  The GET methods for /api/1.2/deliveryservices does not check the 
> length on the `displayName` field, so, it will return whatever is in the 
> database for `displayName`.
> Work Around: Upon getting the Delivery Service information from the API, in 
> order to update/create the Delivery Service via the API you will need to 
> limit the number of characters in the `displayName` to 48.
> NOTE: Other versions of Traffic Ops may be affected.



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

[jira] [Commented] (TC-500) Creating/Updating a Delivery Service via API has length constraint on displayName of 48, but no such constraint in UI code

[Jeremy Mitchell (JIRA)]

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

Jeremy Mitchell commented on TC-500:


This issue exists in the Legacy TO UI but not the new UI (Traffic Portal). In 
my opinion, the priority could probably be reduced. 

> Creating/Updating a Delivery Service via API has length constraint on 
> displayName of 48, but no such constraint in UI code
> --
>
> Key: TC-500
> URL: https://issues.apache.org/jira/browse/TC-500
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Robert Scrimo
>
> Creating/Updating a Delivery Service via API code has length constraint on 
> `displayName` of 48, but there is no such constraint in the UI code so any 
> user can update the value to more than 48 characters.  The Database field is 
> Text which is described as "variable unlimited length" in the Postgres 
> documentation.  However, the value may be limited by the GUI field if such a 
> constraint exists.
> NOTE:  The GET methods for /api/1.2/deliveryservices does not check the 
> length on the `displayName` field, so, it will return whatever is in the 
> database for `displayName`.
> Work Around: Upon getting the Delivery Service information from the API, in 
> order to update/create the Delivery Service via the API you will need to 
> limit the number of characters in the `displayName` to 48.
> NOTE: Other versions of Traffic Ops may be affected.



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

[jira] [Commented] (TC-501) TPv2 installation - better defaults are required

[Jeremy Mitchell (JIRA)]

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

Jeremy Mitchell commented on TC-501:


or maybe you can change this to "improvement" rather than "bug".

> TPv2 installation - better defaults are required
> 
>
> Key: TC-501
> URL: https://issues.apache.org/jira/browse/TC-501
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Portal
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>
> After basic install of traffic-portal based on the documentation, traffic 
> portal failed to launch. this is due to relative pathes to the logs and 
> static files appear in the default configuration.
> Note that the working directory of the server is "/"
> First, the log path (./server/log) does not exists. A possible fix is to 
> change the dir to /opt/traffic_portal/server/log and create the log dir if 
> needed. 
> Second. the files static path should be set to "opt/traffic_portal/public"



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

[jira] [Commented] (TC-508) Import Profile may create parameters duplications

[Jeremy Mitchell (JIRA)]

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

Jeremy Mitchell commented on TC-508:


I'm not sure how that is possible given the fact that there is a unique 
constraint on the parameter table by name, config_file, value. If you look at 
your database do you see that constraint?

> Import Profile may create parameters duplications
> -
>
> Key: TC-508
> URL: https://issues.apache.org/jira/browse/TC-508
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>
> I had an ops server, loaded with the default profiles as published in the 
> web-site.
> I tried to had an exported old ATS 5.3 profile as well.
> It then created a situation where I have 2 parameters with the same "name, 
> file, value" set.
> If for example I delete one of them, the other is deleted as well...



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

[jira] [Resolved] (TC-505) LDAP only users are greeted with a 404 for all UI / API routes

[Jeremy Mitchell (JIRA)]

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

Jeremy Mitchell resolved TC-505.

   Resolution: Fixed
Fix Version/s: 2.1.0

> LDAP only users are greeted with a 404 for all UI / API routes
> --
>
> Key: TC-505
> URL: https://issues.apache.org/jira/browse/TC-505
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Critical
> Fix For: 2.1.0
>
>
> This is because not_ldap => 1 was added to all routes via this PR:
> https://github.com/apache/incubator-trafficcontrol/pull/627
> which results in a 404 for all UI / API routes if you don't have a user entry 
> in the tm_user table.
> Rather than 404, if you login as ldap-only, you should get a 403 (forbidden) 
> with a nice message about what you should do.



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

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

[Hank Beatty (JIRA)]

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

Hank Beatty edited comment on TC-151 at 8/10/17 8:51 PM:
-

[~shemesh] Changing this from "Bug" to "New Feature". This is not a bug for TO 
because TO does not allow for case sensitive XML IDs. Http-test and HTTP-test 
would be the same XML ID and TO would not allow the second to be added.

The TR portion would be a separate issue. However...

> 1. The TR sends a redirect to a host FQDN which contains a lower-case version 
> of the DS XML ID

I don't think this is a bug for TR either. I would expect TR to act this way.

> 2. The TR does not resolve the lower-case version of the host FQDN

I wasn't able to resolve the host either. Maybe it is a lab host? Can you post 
a dig where it is resolving?

If you still think this is a bug please open another jira ticket against the 
component Traffic Router.

Thanks,
Hank


was (Author: hbeatty):
[~shemesh] Changing this from "Bug" to "New Feature". This is not a bug for TO 
because TO does not allow for case sensitive XML IDs. Http-test and HTTP-test 
would be the same XML ID.

The TR portion would be a separate issue. However...

> 1. The TR sends a redirect to a host FQDN which contains a lower-case version 
> of the DS XML ID

I don't think this is a bug for TR either. I would expect TR to act this way.

> 2. The TR does not resolve the lower-case version of the host FQDN

I wasn't able to resolve the host either. Maybe it is a lab host? Can you post 
a dig where it is resolving?

If you still think this is a bug please open another jira ticket against the 
component Traffic Router.

Thanks,
Hank

> 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: New Feature
>  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] [Comment Edited] (TC-151) Delivery Service XML IDs should be limited to lower-case letters

[Hank Beatty (JIRA)]

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

Hank Beatty edited comment on TC-151 at 8/10/17 8:50 PM:
-

[~shemesh] Changing this from "Bug" to "New Feature". This is not a bug for TO 
because TO does not allow for case sensitive XML IDs. Http-test and HTTP-test 
would be the same XML ID.

The TR portion would be a separate issue. However...

> 1. The TR sends a redirect to a host FQDN which contains a lower-case version 
> of the DS XML ID

I don't think this is a bug for TR either. I would expect TR to act this way.

> 2. The TR does not resolve the lower-case version of the host FQDN

I wasn't able to resolve the host either. Maybe it is a lab host? Can you post 
a dig where it is resolving?

If you still think this is a bug please open another jira ticket against the 
component Traffic Router.

Thanks,
Hank


was (Author: hbeatty):
[~shemesh] Changing this from "Bug" to "New Feature". This is not a bug for TO 
because TO does not allow for case sensitive XML IDs.

The TR portion would be a separate issue. However...

> 1. The TR sends a redirect to a host FQDN which contains a lower-case version 
> of the DS XML ID

I don't think this is a bug for TR either. I would expect TR to act this way.

> 2. The TR does not resolve the lower-case version of the host FQDN

I wasn't able to resolve the host either. Maybe it is a lab host? Can you post 
a dig where it is resolving?

If you still think this is a bug please open another jira ticket against the 
component Traffic Router.

Thanks,
Hank

> 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: New Feature
>  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] [Commented] (TC-505) LDAP only users are greeted with a 404 for all UI / API routes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-505:
---

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/41/



> LDAP only users are greeted with a 404 for all UI / API routes
> --
>
> Key: TC-505
> URL: https://issues.apache.org/jira/browse/TC-505
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Critical
>
> This is because not_ldap => 1 was added to all routes via this PR:
> https://github.com/apache/incubator-trafficcontrol/pull/627
> which results in a 404 for all UI / API routes if you don't have a user entry 
> in the tm_user table.
> Rather than 404, if you login as ldap-only, you should get a 403 (forbidden) 
> with a nice message about what you should do.



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

[GitHub] incubator-trafficcontrol issue #793: [TC-505] - throws 403 (rather than 404)...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/41/



---
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] [Commented] (TC-505) LDAP only users are greeted with a 404 for all UI / API routes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-505:
---

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/40/



> LDAP only users are greeted with a 404 for all UI / API routes
> --
>
> Key: TC-505
> URL: https://issues.apache.org/jira/browse/TC-505
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Critical
>
> This is because not_ldap => 1 was added to all routes via this PR:
> https://github.com/apache/incubator-trafficcontrol/pull/627
> which results in a 404 for all UI / API routes if you don't have a user entry 
> in the tm_user table.
> Rather than 404, if you login as ldap-only, you should get a 403 (forbidden) 
> with a nice message about what you should do.



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

[GitHub] incubator-trafficcontrol issue #793: [TC-505] - throws 403 (rather than 404)...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/40/



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

[GitHub] incubator-trafficcontrol pull request #793: [TC-505] - throws 403 (rather th...

[dangogh]

Github user dangogh commented on a diff in the pull request:


https://github.com/apache/incubator-trafficcontrol/pull/793#discussion_r132557250
  
--- Diff: traffic_ops/app/conf/cdn.conf ---
@@ -13,8 +13,9 @@
access_control_allow_origin => '*'
},
to => {
-   base_url   => 'http://localhost:3000',# 
this is where traffic ops app resides
-   email_from => 'no-re...@traffic-ops-domain.com'   # 
traffic ops email address
+   base_url=> 
'http://localhost:3000',

 # this is where traffic ops app resides
+   email_from  => 
'no-re...@traffic-ops-domain.com',  

 # traffic ops email address
+   no_account_found_msg=> 'A Traffic Ops user account is 
required for access. Please contact your Traffic Ops user administrator.' # 
message to display if no TO account is found in tm_user
},
--- End diff --

TABs added in there?


---
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] [Commented] (TC-505) LDAP only users are greeted with a 404 for all UI / API routes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-505:
---

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/39/



> LDAP only users are greeted with a 404 for all UI / API routes
> --
>
> Key: TC-505
> URL: https://issues.apache.org/jira/browse/TC-505
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Critical
>
> This is because not_ldap => 1 was added to all routes via this PR:
> https://github.com/apache/incubator-trafficcontrol/pull/627
> which results in a 404 for all UI / API routes if you don't have a user entry 
> in the tm_user table.
> Rather than 404, if you login as ldap-only, you should get a 403 (forbidden) 
> with a nice message about what you should do.



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

[GitHub] incubator-trafficcontrol issue #793: [TC-505] - throws 403 (rather than 404)...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/39/



---
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-173) API on port 3333 doesn't start if 443 is first in server.xml

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-173:
---
Fix Version/s: 2.2.0

> 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
> Fix For: 2.2.0
>
>
> 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] [Commented] (TC-173) API on port 3333 doesn't start if 443 is first in server.xml

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-173:


The workaround is to remove the 443 connector line from the config.


> 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
> Fix For: 2.2.0
>
>
> 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] [Commented] (TC-169) TR download the RGB file continuously when the same RGB file on server

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-169:


[~zhilhuan] Can you update your PR against the latest and I'll try to get it 
someone to review and merge it?

> 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] [Closed] (TC-167) api/1.1/cachegroupparameter.t test fails

[Hank Beatty (JIRA)]

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

Hank Beatty closed TC-167.
--
Resolution: Fixed

fixed with 2978c6571b93b801cd137c4b53920f554813ce90

> api/1.1/cachegroupparameter.t test fails 
> -
>
> Key: TC-167
> URL: https://issues.apache.org/jira/browse/TC-167
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
>Reporter: Jan van Doorn
>Assignee: Jan van Doorn
>Priority: Minor
>  Labels: api_cachegroupparameter
> Fix For: 2.0.0
>
>




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

[jira] [Commented] (TC-165) Warning "Useless use of distinct on a grouped resultset"

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-165:


[~dangogh] Can we re-classify this as an improvement since the way it is 
doesn't break anything?

> Warning "Useless use of distinct on a grouped resultset"
> 
>
> Key: TC-165
> URL: https://issues.apache.org/jira/browse/TC-165
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
>Reporter: Dan Kirkwood
>Priority: Trivial
>  Labels: integration_testing
>
> Looks like this just is a warning,  but ought to be looked into..   Happens 
> during integration tests (`prove t_integration`):
> DBIx::Class::ResultSet::_resolved_attrs(): Useless use of distinct on a 
> grouped resultset ('distinct' is ignored when a 'group_by' is present) at 
> /Users/dkirkw001c/Code/src/github.com/dangogh/incubator-trafficcontrol/traffic_ops/app/lib/UI/Topology.pm
>  line 79



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

[jira] [Commented] (TC-161) ort does not restart ATS when it should

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-161:


[~weifensh] Can you update your PR against the latest traffic_ops_ort.pl? Once 
done I'll test and merge.

> ort does not restart ATS when it should
> ---
>
> Key: TC-161
> URL: https://issues.apache.org/jira/browse/TC-161
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops ORT
>Affects Versions: 2.1.0
>Reporter: John Shen
>Assignee: John Shen
>
> ort does not restart ATS when ATS is already running



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

[jira] [Updated] (TC-161) ort does not restart ATS when it should

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-161:
---
Affects Version/s: 2.1.0

> ort does not restart ATS when it should
> ---
>
> Key: TC-161
> URL: https://issues.apache.org/jira/browse/TC-161
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops ORT
>Affects Versions: 2.1.0
>Reporter: John Shen
>Assignee: John Shen
>
> ort does not restart ATS when ATS is already running



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

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-118:
---
Fix Version/s: 2.2.0

> 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: 2.1.0, 2.0.0, 1.8.0, 1.7.0, 2.2.0
>Reporter: Oren Shemesh
>Priority: Minor
>  Labels: configuration, crconfig
> Fix For: 2.2.0
>
>
> 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-118) Traffic Ops should get it's name from some confioguration when generating CrConfig

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-118:
---
Affects Version/s: 2.2.0

> 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: 2.1.0, 2.0.0, 1.8.0, 1.7.0, 2.2.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] [Created] (TC-508) Import Profile may create parameters duplications

[Nir Sopher (JIRA)]

Nir Sopher created TC-508:
-

 Summary: Import Profile may create parameters duplications
 Key: TC-508
 URL: https://issues.apache.org/jira/browse/TC-508
 Project: Traffic Control
  Issue Type: Bug
  Components: Traffic Ops
Affects Versions: 2.1.0
Reporter: Nir Sopher


I had an ops server, loaded with the default profiles as published in the 
web-site.
I tried to had an exported old ATS 5.3 profile as well.
It then created a situation where I have 2 parameters with the same "name, 
file, value" set.
If for example I delete one of them, the other is deleted as well...



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-336:
---

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/38/



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

[GitHub] incubator-trafficcontrol issue #790: [TC-336] build ui for managing url sig ...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/38/



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

[GitHub] incubator-trafficcontrol issue #795: exclude traffic_ops_golang vendor depen...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/37/



---
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-69) Upgrade Tomcat Version for Traffic Router

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-69:
--
Fix Version/s: 2.2.0

> 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
>Affects Versions: 2.1.0
>Reporter: David Neuman
>Assignee: David Neuman
>  Labels: tomcat
> Fix For: 2.2.0
>
>
> 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-69) Upgrade Tomcat Version for Traffic Router

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-69:
--
Affects Version/s: 2.1.0

> 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
>Affects Versions: 2.1.0
>Reporter: David Neuman
>Assignee: David Neuman
>  Labels: tomcat
> Fix For: 2.2.0
>
>
> 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-59) Traffic Ops Client should return HTTP body on Error response

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-59:
--
Affects Version/s: 2.1.0

> 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
>Affects Versions: 2.1.0
>Reporter: David Neuman
>Priority: Minor
>  Labels: error_response
> Fix For: 2.2.0
>
>
> 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-59) Traffic Ops Client should return HTTP body on Error response

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-59:
--
Fix Version/s: 2.2.0

> 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
>Affects Versions: 2.1.0
>Reporter: David Neuman
>Priority: Minor
>  Labels: error_response
> Fix For: 2.2.0
>
>
> 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 issue #795: exclude traffic_ops_golang vendor depen...

[dangogh]

Github user dangogh commented on the issue:

https://github.com/apache/incubator-trafficcontrol/pull/795
  
test this please


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

[GitHub] incubator-trafficcontrol issue #795: exclude traffic_ops_golang vendor depen...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/35/



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

[GitHub] incubator-trafficcontrol pull request #795: exclude traffic_ops_golang vendo...

[dangogh]

GitHub user dangogh opened a pull request:

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

exclude traffic_ops_golang vendor dependency in rat report

rat report shows go-sqlmock is not properly licensed,  but it is documented 
in the LICENSE file.  Adds to .rat-excludes so rat won't report it.

@rob05c -- your first merge?

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

$ git pull https://github.com/dangogh/incubator-trafficcontrol rat-exclude

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

https://github.com/apache/incubator-trafficcontrol/pull/795.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 #795


commit 8c1153abddff1fedf8f9cd79cdb824bd4ed5f06d
Author: Dan Kirkwood 
Date:   2017-08-10T17:32:45Z

exclude traffic_ops_golang vendor dependency in rat report




---
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-118) Traffic Ops should get it's name from some confioguration when generating CrConfig

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-118:
---
Affects Version/s: 1.8.0
   2.0.0
   2.1.0

> 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: 2.1.0, 2.0.0, 1.8.0, 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] [Commented] (TC-118) Traffic Ops should get it's name from some confioguration when generating CrConfig

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-118:


Will not be fixed in 2.1

> 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: 2.1.0, 2.0.0, 1.8.0, 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)

test -- please ignore

[Dan Kirkwood]

I noticed that build failure messages were not appearing..   Just
testing this email alias...

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

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-151:


[~shemesh] Changing this from "Bug" to "New Feature". This is not a bug for TO 
because TO does not allow for case sensitive XML IDs.

The TR portion would be a separate issue. However...

> 1. The TR sends a redirect to a host FQDN which contains a lower-case version 
> of the DS XML ID

I don't think this is a bug for TR either. I would expect TR to act this way.

> 2. The TR does not resolve the lower-case version of the host FQDN

I wasn't able to resolve the host either. Maybe it is a lab host? Can you post 
a dig where it is resolving?

If you still think this is a bug please open another jira ticket against the 
component Traffic Router.

Thanks,
Hank

> 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: New Feature
>  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-151) Delivery Service XML IDs should be limited to lower-case letters

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-151:
---
Issue Type: New Feature  (was: Bug)

> 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: New Feature
>  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] [Commented] (TC-507) ORT should not use the reverse proxy for security-sensitive files

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-507:
---

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/34/



> ORT should not use the reverse proxy for security-sensitive files
> -
>
> Key: TC-507
> URL: https://issues.apache.org/jira/browse/TC-507
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops ORT
>Affects Versions: 2.1.0
>Reporter: Derek Gelinas
>Assignee: Derek Gelinas
>
> ORT should bypass the reverse proxy in cases where the files being requested 
> are of a sensitive nature.



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

[GitHub] incubator-trafficcontrol issue #794: [TC-507] bypass reverse proxy on TLS an...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/34/



---
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] [Commented] (TC-507) ORT should not use the reverse proxy for security-sensitive files

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-507:
---

Github user dg4prez commented on the issue:

https://github.com/apache/incubator-trafficcontrol/pull/794
  
tested and ready for merge.


> ORT should not use the reverse proxy for security-sensitive files
> -
>
> Key: TC-507
> URL: https://issues.apache.org/jira/browse/TC-507
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops ORT
>Affects Versions: 2.1.0
>Reporter: Derek Gelinas
>Assignee: Derek Gelinas
>
> ORT should bypass the reverse proxy in cases where the files being requested 
> are of a sensitive nature.



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

[GitHub] incubator-trafficcontrol issue #794: [TC-507] bypass reverse proxy on TLS an...

[dg4prez]

Github user dg4prez commented on the issue:

https://github.com/apache/incubator-trafficcontrol/pull/794
  
tested and ready for merge.


---
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] [Created] (TC-507) ORT should not use the reverse proxy for security-sensitive files

[Derek Gelinas (JIRA)]

Derek Gelinas created TC-507:


 Summary: ORT should not use the reverse proxy for 
security-sensitive files
 Key: TC-507
 URL: https://issues.apache.org/jira/browse/TC-507
 Project: Traffic Control
  Issue Type: Improvement
  Components: Traffic Ops ORT
Affects Versions: 2.1.0
Reporter: Derek Gelinas
Assignee: Derek Gelinas


ORT should bypass the reverse proxy in cases where the files being requested 
are of a sensitive nature.



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

[GitHub] incubator-trafficcontrol pull request #794: bypass reverse proxy on TLS and ...

[dg4prez]

GitHub user dg4prez opened a pull request:

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

bypass reverse proxy on TLS and url_sig requests

Prevents ORT from using the reverse proxy for sensitive configuration files 
like TLS certificates/keys and url signatures.

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

$ git pull https://github.com/dg4prez/incubator-trafficcontrol ort_security

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

https://github.com/apache/incubator-trafficcontrol/pull/794.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 #794


commit 36e14cbcf0eb23ada97bad8f3e1aa03a777bb460
Author: Derek Gelinas 
Date:   2017-08-10T16:08:07Z

bypass reverse proxy on TLS and url_sig requests




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

[GitHub] incubator-trafficcontrol pull request #729: Traffic Ops Golang Incremental R...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-445) Traffic Ops API Rewrite: Implement /api/1.2/servers

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson updated TC-445:
--
Description: Implement the second TO Golang endpoint   (was: Implement the 
first TO Golang endpoint using the MojoCookies+Capabilities)

> Traffic Ops API Rewrite: Implement /api/1.2/servers
> ---
>
> Key: TC-445
> URL: https://issues.apache.org/jira/browse/TC-445
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>
> Implement the second TO Golang endpoint 



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

[jira] [Updated] (TC-445) Traffic Ops API Rewrite: Implement /api/1.2/servers

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson updated TC-445:
--
Summary: Traffic Ops API Rewrite: Implement /api/1.2/servers  (was: Traffic 
Ops API Rewrite: Implement /api/1.2/users with MojoCookie+Capabilities)

> Traffic Ops API Rewrite: Implement /api/1.2/servers
> ---
>
> Key: TC-445
> URL: https://issues.apache.org/jira/browse/TC-445
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>
> Implement the first TO Golang endpoint using the MojoCookies+Capabilities



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

[GitHub] incubator-trafficcontrol pull request #789: adds docs/ prefix to hrefs on ve...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Commented] (TC-501) TPv2 installation - better defaults are required

[Jeremy Mitchell (JIRA)]

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

Jeremy Mitchell commented on TC-501:


[~hbeatty] - I personally think this is a lower priority as [~nirsopher] wasn't 
aware of the comments that must be followed to get TP installed. [~nirsopher] - 
can you lower the priority or switch it to 2.2?

> TPv2 installation - better defaults are required
> 
>
> Key: TC-501
> URL: https://issues.apache.org/jira/browse/TC-501
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Portal
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>
> After basic install of traffic-portal based on the documentation, traffic 
> portal failed to launch. this is due to relative pathes to the logs and 
> static files appear in the default configuration.
> Note that the working directory of the server is "/"
> First, the log path (./server/log) does not exists. A possible fix is to 
> change the dir to /opt/traffic_portal/server/log and create the log dir if 
> needed. 
> Second. the files static path should be set to "opt/traffic_portal/public"



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-336:
---

Github user mitchell852 commented on the issue:

https://github.com/apache/incubator-trafficcontrol/pull/790
  
you might want to consider adding a confirm dialog to the generate button. 
i.e. "Are you sure you want to generate url sig keys?" - search for 
dialog.confirm to see other places that use it.


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

[GitHub] incubator-trafficcontrol issue #790: [TC-336] build ui for managing url sig ...

[mitchell852]

Github user mitchell852 commented on the issue:

https://github.com/apache/incubator-trafficcontrol/pull/790
  
you might want to consider adding a confirm dialog to the generate button. 
i.e. "Are you sure you want to generate url sig keys?" - search for 
dialog.confirm to see other places that use it.


---
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-159) traffic_monitor_config.js is corrupt.

[Hank Beatty (JIRA)]

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

Hank Beatty closed TC-159.
--
Resolution: Won't Fix

This has been corrected in a later release and we do not intend to backport to 
1.8.

> 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] [Commented] (TC-152) misc/release.pl incorrectly updates the VERSION file

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-152:


[~dangogh] Is this still an issue? If so, are we planning to fix for 2.1?

> 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] [Commented] (TC-149) GET api/1.2/deliveryservices/hostname/:hostname/sslkeys returns 400

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-149:


[~mitchell...@apache.org] Is this still an issue? If so, are we planning on 
fixing for 2.1?

> 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] [Commented] (TC-123) UI route (/healthdatadeliveryservice) is broken as no related html template exists

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-123:


[~mitchell...@apache.org] Is this still an issue? If so, are we planning on 
fixing for 2.1?

> 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.1.0, 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

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-123:
---
Affects Version/s: 2.1.0

> 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.1.0, 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] [Closed] (TC-120) The zero size file can't be updated by Traffic Ops ORT

[Hank Beatty (JIRA)]

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

Hank Beatty closed TC-120.
--
Resolution: Fixed

closed by 0e8978bda8cc1bf9858b4656f7399e37c69ec0e1

> The zero size file can't be updated by Traffic Ops ORT
> --
>
> Key: TC-120
> URL: https://issues.apache.org/jira/browse/TC-120
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops ORT
>Affects Versions: 1.8.0
>Reporter: Jifeng Yang
>Assignee: Jifeng Yang
>
> The ORT doesn't update a file if the file is zero size.
> The configuration file may become zero size file by some reason (such as by 
> accident). If a file is zero size, it can't be updated any more.



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

[jira] [Commented] (TC-116) remap.config order is different on master (postgres) than it is on 1.8.

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-116:


[~jvd] Has this been resolved? If not, are we planning on fixing for 2.1?

> remap.config order is different on master (postgres) than it is on 1.8.
> ---
>
> Key: TC-116
> URL: https://issues.apache.org/jira/browse/TC-116
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Jan van Doorn
>Assignee: Jan van Doorn
>  Labels: remap.config
>




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

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

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-115:


[~dg4prez] It looks like this is ready to be merged. Can you merge it into 
master and also do a backport to 2.1?

> 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] [Commented] (TC-105) Change the default setting for RAM cache algorithm in the seeds and default data

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-105:


[~jvd] Is this still an issue? If so, are we planning on fixing in 2.1?

> Change the default setting for RAM cache algorithm in the seeds and default 
> data
> 
>
> Key: TC-105
> URL: https://issues.apache.org/jira/browse/TC-105
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Jan van Doorn
>Priority: Trivial
>  Labels: ram_cache
>
> CONFIG proxy.config.cache.ram_cache.algorithm INT 1
> CONFIG proxy.config.cache.ram_cache.use_seen_filter INT 1
> Should be the defaults in all ATS profiles.



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

[jira] [Commented] (TC-104) httpsPort key is missing in the CRConfig contentRouters section for 1.8

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-104:


[~jvd] Is this still an issue? If so, are we planning on fixing in 2.1?

> httpsPort key is missing in the CRConfig contentRouters section for 1.8
> ---
>
> Key: TC-104
> URL: https://issues.apache.org/jira/browse/TC-104
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Jan van Doorn
>Priority: Minor
>  Labels: crconfig
>
> Don't think it's a show stopper, it'll default to 443.



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

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

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-100:


[~mitchell...@apache.org] Is this still an issue? If so, are we planning on 
fixing in 2.1?

> 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] [Closed] (TC-99) api/{version}/cdns/:cdn_name/health returns the health of all cdns

[Hank Beatty (JIRA)]

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

Hank Beatty closed TC-99.
-
Resolution: Fixed

closed by 480d8887f01a0ef0445f85ee11e8b65ba61d962f

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

[Hank Beatty (JIRA)]

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

Hank Beatty closed TC-98.
-
Resolution: Fixed

fixed by f8cd76b23e280df926fe2121ca2571eeac1e9191

> 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-504) TPv2 - delivery service globalMaxMbps and globalMaxTps need to be verified as INT

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TC-504:
---

Github user asfgit closed the pull request at:

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


> TPv2 - delivery service globalMaxMbps and globalMaxTps need to be verified as 
> INT
> -
>
> Key: TC-504
> URL: https://issues.apache.org/jira/browse/TC-504
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Portal
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
> Fix For: 2.1.0
>
>
> When creating or editing DNS* or HTTP* delivery services through the traffic 
> portal validation is currently occurring that prevents setting the value of 
> globalMaxMbps and globalMaxTps to its proper data type - INT.



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

[GitHub] incubator-trafficcontrol pull request #792: [Backport] [TC-504] - fixes numb...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Commented] (TC-69) Upgrade Tomcat Version for Traffic Router

[David Neuman (JIRA)]

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

David Neuman commented on TC-69:


This will not be ready for 2.1.  I am targeting 2.2 for the new version of 
Tomcat.

Thanks,
Dave

> 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-59) Traffic Ops Client should return HTTP body on Error response

[David Neuman (JIRA)]

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

David Neuman updated TC-59:
---
Priority: Minor  (was: Major)

> 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
>Priority: Minor
>  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] [Commented] (TC-59) Traffic Ops Client should return HTTP body on Error response

[David Neuman (JIRA)]

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

David Neuman commented on TC-59:


This has not been resolved and is not being planned for 2.1.  
Downgrading to Minor.

> 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
>Priority: Minor
>  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] [Closed] (TC-57) Build process not changing directory and reading configuration file

[Steve Malenfant (JIRA)]

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

Steve Malenfant closed TC-57.
-

> 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
>Assignee: Steve Malenfant
>Priority: Minor
>  Labels: build
> Fix For: 1.9.0
>
>
> 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] [Closed] (TC-29) Traffic Router TPS for HTTPS requests diminishes when reloading certificates

[David Neuman (JIRA)]

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

David Neuman closed TC-29.
--
Resolution: Fixed
  Assignee: David Neuman

This was resolved in 2.0.0.  
Thanks,
Dave

> 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
>Assignee: 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] [Resolved] (TC-57) Build process not changing directory and reading configuration file

[Steve Malenfant (JIRA)]

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

Steve Malenfant resolved TC-57.
---
   Resolution: Not A Bug
 Assignee: Steve Malenfant
Fix Version/s: 1.9.0

> 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
>Assignee: Steve Malenfant
>Priority: Minor
>  Labels: build
> Fix For: 1.9.0
>
>
> 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] [Commented] (TC-57) Build process not changing directory and reading configuration file

[Steve Malenfant (JIRA)]

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

Steve Malenfant commented on TC-57:
---

This working fine now. You need to run './build/build.sh" from the root of the 
git directory. Looks like I was doing a "cd build" first.


> 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] [Commented] (TC-85) Should use "dest_ip" instead of "dest_domain" in "parent.config" and "cache.config" when ofqdn is ip

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-85:
---

[~dg4prez] Were you able to finish reviewing the PR associated with this issue? 
Are we going to merge it into 2.1?

> Should use "dest_ip" instead of "dest_domain" in "parent.config" and 
> "cache.config" when ofqdn is ip
> 
>
> Key: TC-85
> URL: https://issues.apache.org/jira/browse/TC-85
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Jifeng Yang
>Assignee: Jifeng Yang
>  Labels: dest_domain, parent.config
>
> Should use "dest_ip" instead of "dest_domain" in "parent.config" and 
> "cache.config" when ofqdn is ip.



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

[jira] [Commented] (TC-77) Docker files need small updates

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-77:
---

[~jvd] Is this still and issue? If so, are we going to fix in 2.1?

> Docker files need small updates
> ---
>
> Key: TC-77
> URL: https://issues.apache.org/jira/browse/TC-77
> Project: Traffic Control
>  Issue Type: Bug
>  Components: All
>Affects Versions: 1.8.0
>Reporter: Jan van Doorn
>Assignee: Jan van Doorn
>Priority: Minor
>
> Docker files need some minor updates. 
> 1) Traffic Ops: centos question is different (centos72.), and some other 
> minor things
> 2) riak needs search installed : 
> http://trafficcontrol.apache.org/docs/latest/admin/traffic_vault.html#configuring-riak-search
> I will try to create a PR once I'm done w 1.8 testing, there may be more. 



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

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

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-76:
---

[~psudaemon] [~jrushford] Is this still an issue? If so, are we going to fix in 
2.1?

> 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] [Commented] (TC-69) Upgrade Tomcat Version for Traffic Router

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-69:
---

[~neuman] It looks like Tomcat 6 is now EOL. Has this been fixed in 2.1? I know 
we are still using 6.0.48.

> 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] [Commented] (TC-59) Traffic Ops Client should return HTTP body on Error response

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-59:
---

[~neuman] [~hbeatty] Has this been resolved? If not are we going to try to fix 
in 2.1?

> 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] [Commented] (TC-57) Build process not changing directory and reading configuration file

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-57:
---

[~smalenfant] Has this been resolved? If not, are we going to try to fix it in 
2.1?

> 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] [Commented] (TC-48) Steering Delivery Test Cases

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-48:
---

[~dewrich] [~mitchell...@apache.org] The PR was merged against master. Can this 
issue be closed?

> 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] [Commented] (TC-44) TR fd leak observed when new HTTPS DS is added without certificate

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-44:
---

[~weifensh] [~tackerman] [~neuman] Does this still exist? If so, are we 
planning on fixing for 2.1?

> 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] [Commented] (TC-29) Traffic Router TPS for HTTPS requests diminishes when reloading certificates

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-29:
---

[~neuman]  [~tackerman] I believe this is resolved and can be closed. Can one 
of you verify and close if that is the case?

Thanks,
Hank

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