[jira] [Closed] (TC-441) TPv2 - implement password reset functionality
[ https://issues.apache.org/jira/browse/TC-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty closed TC-441. -- Resolution: Fixed > TPv2 - implement password reset functionality > - > > Key: TC-441 > URL: https://issues.apache.org/jira/browse/TC-441 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell > > implement password reset functionality -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-533) DS SSL key apis needs to have tenancy check in place
[
https://issues.apache.org/jira/browse/TC-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty closed TC-533.
--
Resolution: Fixed
> DS SSL key apis needs to have tenancy check in place
>
>
> Key: TC-533
> URL: https://issues.apache.org/jira/browse/TC-533
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Nir Sopher
> Fix For: 2.1.0, 2.2.0
>
>
> Tenancy was introduced in 2.1, however, by default it is turned off via the
> use_tenancy parameter but when activated it is used to limit the scope of
> delivery services that a user can act on.
> The following APIs needs to check tenancy to ensure users cannot act on ds's
> that they don't have access to.
> get("/api/$version/deliveryservices/xmlId/#xmlid/sslkeys
> post("/api/$version/deliveryservices/sslkeys/generate
> post("/api/$version/deliveryservices/sslkeys/add
> get("/api/$version/deliveryservices/xmlId/:xmlid/sslkeys/delete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TC-374) `systemctl stop traffic_ops` does not kill all processes
[
https://issues.apache.org/jira/browse/TC-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty closed TC-374.
--
Resolution: Fixed
> `systemctl stop traffic_ops` does not kill all processes
>
>
> Key: TC-374
> URL: https://issues.apache.org/jira/browse/TC-374
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
> Labels: systemctl
> Fix For: 2.1.0, 2.2.0
>
>
> not sure why it gets in this state, but traffic_ops processes sometimes get
> in a state where the parent process is the root (1) for many of the
> script/cdn workers. The init.d script doesn't stop them because they don't
> match the pid in `/var/run/traffic_ops.pid`.
> This needs to be more robust.
> Example: on my test VM, if I run this, I see multiple parent processes:
> {quote}
> ps -ef | grep script/cdn|grep -v root | awk '\{print $3\}' | sort -u
> 1
> 22713
> 29306
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-514) ORT: Change Traffic Ops hostname in middle of ORT run
[
https://issues.apache.org/jira/browse/TC-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-514:
---
Fix Version/s: 2.1.0
> ORT: Change Traffic Ops hostname in middle of ORT run
> -
>
> Key: TC-514
> URL: https://issues.apache.org/jira/browse/TC-514
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops ORT
>Affects Versions: 2.1.0, 2.2.0
> Environment: Traffic Ops 2.1 and ORT 2.1
>Reporter: Steve Malenfant
>Assignee: Steve Malenfant
>Priority: Minor
> Fix For: 2.1.0, 2.2.0
>
>
> I'm not sure if this is 2.1 specifics... Worth discussing.
> - Could this prevent load balancing traffic ops from working?
> - Cookies might be different (you need to sync secrets?). These are in the
> cdn.conf and not the database...
> When you instruct the traffic_ops_ort to go to a secondary Traffic Ops, it
> will start on the CLI designated but will move back to the primary during the
> "Start processing packages" process.
> Code in question :
> https://github.com/apache/incubator-trafficcontrol/blob/2.1.x/traffic_ops/bin/traffic_ops_ort.pl#L201
> {code:java}
> [root@edge06 ~]# /opt/ort/traffic_ops_ort.pl -dispersion=0 report DEBUG
> https://traffic-ops-0002.coxlab.net chs:w@term@rk
> Mon Aug 14 13:29:06 UTC 2017
> DEBUG OS release is EL7.
> DEBUG Script running in report mode.
> 302
> DEBUG https://traffic-ops-0002.coxlab.net/login returned HTTP 302.
> DEBUG Cookie is
> mojolicious=eyJhdXRoX2RhdGEi4iJjaHMiLCJleHBpcmVzIjoxNTAyNzMxNzQ2fQ136010205dc8d4951e2e2194b6b463eb3d141f1e.
> DEBUG YUM_OPTS: .
> DEBUG Total connections in LWP cache: 1
> INFO Traffic Ops host: https://traffic-ops-0002.coxlab.net
> ...
> INFO: Start processing packages
> DEBUG Total connections in LWP cache: 1
> INFO Traffic Ops host: https://traffic-ops-0001.coxlab.net
> DEBUG lwp_get called with /ort/psp6cdedge06/packages
> ERROR https://traffic-ops-0001.coxlab.net/ort/edge06/packages returned HTTP
> 401! Unauthorized
> ERROR result for https://traffic-ops-0001/ort/psp6cdedge06/packages is:
>
[jira] [Closed] (TC-519) TP - tenants menu item mistakenly removed from TP
[ https://issues.apache.org/jira/browse/TC-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty closed TC-519. -- Resolution: Fixed merged PR > TP - tenants menu item mistakenly removed from TP > - > > Key: TC-519 > URL: https://issues.apache.org/jira/browse/TC-519 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell > Fix For: 2.1.0, 2.2.0 > > > Somehow the tenants menu was mistakenly removed from TP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-533) DS SSL key apis needs to have tenancy check in place
[
https://issues.apache.org/jira/browse/TC-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-533:
---
Fix Version/s: 2.2.0
2.1.0
> DS SSL key apis needs to have tenancy check in place
>
>
> Key: TC-533
> URL: https://issues.apache.org/jira/browse/TC-533
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Nir Sopher
> Fix For: 2.1.0, 2.2.0
>
>
> Tenancy was introduced in 2.1, however, by default it is turned off via the
> use_tenancy parameter but when activated it is used to limit the scope of
> delivery services that a user can act on.
> The following APIs needs to check tenancy to ensure users cannot act on ds's
> that they don't have access to.
> get("/api/$version/deliveryservices/xmlId/#xmlid/sslkeys
> post("/api/$version/deliveryservices/sslkeys/generate
> post("/api/$version/deliveryservices/sslkeys/add
> get("/api/$version/deliveryservices/xmlId/:xmlid/sslkeys/delete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-535) DS URL sig key apis needs to have tenancy check in place
[
https://issues.apache.org/jira/browse/TC-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-535:
---
Fix Version/s: 2.2.0
2.1.0
> DS URL sig key apis needs to have tenancy check in place
>
>
> Key: TC-535
> URL: https://issues.apache.org/jira/browse/TC-535
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Nir Sopher
> Fix For: 2.1.0, 2.2.0
>
>
> Tenancy was introduced in 2.1, however, by default it is turned off via the
> use_tenancy parameter but when activated it is used to limit the scope of
> delivery services that a user can act on.
> The following APIs needs to check tenancy to ensure users cannot act on ds's
> that they don't have access to.
> post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/generate
> post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/copyFromXmlId/:copyFromXmlId
> get("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys
--
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
[ https://issues.apache.org/jira/browse/TC-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16132003#comment-16132003 ] Hank Beatty commented on TC-85: --- [~jifengyang] Can you rebase your PR and fix any conflicts? > 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 >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jifeng Yang >Assignee: Jifeng Yang > Labels: dest_domain, parent.config > Fix For: 2.1.0, 2.2.0 > > > 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] [Updated] (TC-521) TPv2 - http-parser dependency cannot be resolved
[ https://issues.apache.org/jira/browse/TC-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-521: --- Fix Version/s: 2.2.0 > TPv2 - http-parser dependency cannot be resolved > - > > Key: TC-521 > URL: https://issues.apache.org/jira/browse/TC-521 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Blocker > Fix For: 2.1.0, 2.2.0 > > > Therefore the Traffic Portal build fails. > More details of the error: https://bugs.centos.org/view.php?id=13669=1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-521) TPv2 - http-parser dependency cannot be resolved
[ https://issues.apache.org/jira/browse/TC-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-521: --- Affects Version/s: 2.2.0 > TPv2 - http-parser dependency cannot be resolved > - > > Key: TC-521 > URL: https://issues.apache.org/jira/browse/TC-521 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Blocker > Fix For: 2.1.0, 2.2.0 > > > Therefore the Traffic Portal build fails. > More details of the error: https://bugs.centos.org/view.php?id=13669=1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-519) TP - tenants menu item mistakenly removed from TP
[ https://issues.apache.org/jira/browse/TC-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-519: --- Fix Version/s: 2.2.0 > TP - tenants menu item mistakenly removed from TP > - > > Key: TC-519 > URL: https://issues.apache.org/jira/browse/TC-519 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell > Fix For: 2.1.0, 2.2.0 > > > Somehow the tenants menu was mistakenly removed from TP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-516) Deleting a DS thru the API should also delete all SSL keys (if applicable)
[ https://issues.apache.org/jira/browse/TC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16129083#comment-16129083 ] Hank Beatty commented on TC-516: [~mitchell...@apache.org] Yeah, I'm going to do that. I just wanted to nail down those that we definitely wanted to fix for 2.1 and I think I'm almost there. > Deleting a DS thru the API should also delete all SSL keys (if applicable) > -- > > Key: TC-516 > URL: https://issues.apache.org/jira/browse/TC-516 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jeremy Mitchell > Fix For: 2.1.0, 2.2.0 > > > There are currently 4 protocols for a DS: > 0 - HTTP > 1 - HTTPS > 2 - HTTP AND HTTPS > 3 - HTTP TO HTTPS > Currently, if you delete a DS thru the API, SSL keys are not deleted. This > should occur if ds.protocol > 0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-519) TP - tenants menu item mistakenly removed from TP
[ https://issues.apache.org/jira/browse/TC-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-519: --- Affects Version/s: 2.2.0 > TP - tenants menu item mistakenly removed from TP > - > > Key: TC-519 > URL: https://issues.apache.org/jira/browse/TC-519 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell > Fix For: 2.1.0, 2.2.0 > > > Somehow the tenants menu was mistakenly removed from TP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-516) Deleting a DS thru the API should also delete all SSL keys (if applicable)
[ https://issues.apache.org/jira/browse/TC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-516: --- Fix Version/s: 2.2.0 2.1.0 > Deleting a DS thru the API should also delete all SSL keys (if applicable) > -- > > Key: TC-516 > URL: https://issues.apache.org/jira/browse/TC-516 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jeremy Mitchell > Fix For: 2.1.0, 2.2.0 > > > There are currently 4 protocols for a DS: > 0 - HTTP > 1 - HTTPS > 2 - HTTP AND HTTPS > 3 - HTTP TO HTTPS > Currently, if you delete a DS thru the API, SSL keys are not deleted. This > should occur if ds.protocol > 0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-490) mso.qstring_handling parameter is checked but not documented
[
https://issues.apache.org/jira/browse/TC-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-490:
---
Fix Version/s: 2.2.0
2.1.0
> 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, 2.2.0
>Reporter: Matt Mills
>Priority: Blocker
> Fix For: 2.1.0, 2.2.0
>
>
> 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-515) Traffic Portal - Show human readable protocol on DS page
[ https://issues.apache.org/jira/browse/TC-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-515: --- Fix Version/s: 2.2.0 2.1.0 > Traffic Portal - Show human readable protocol on DS page > > > Key: TC-515 > URL: https://issues.apache.org/jira/browse/TC-515 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0, 2.2.0 >Reporter: David Neuman >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.1.0, 2.2.0 > > > In the TO UI, the delivery service protocol is converted from an int (0,1,2) > to a human readable string (http, https, http and https, etc). The new TO > portal just shows the int but it should show the human readable string. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-516) Deleting a DS thru the API should also delete all SSL keys (if applicable)
[ https://issues.apache.org/jira/browse/TC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-516: --- Affects Version/s: 2.2.0 > Deleting a DS thru the API should also delete all SSL keys (if applicable) > -- > > Key: TC-516 > URL: https://issues.apache.org/jira/browse/TC-516 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jeremy Mitchell > > There are currently 4 protocols for a DS: > 0 - HTTP > 1 - HTTPS > 2 - HTTP AND HTTPS > 3 - HTTP TO HTTPS > Currently, if you delete a DS thru the API, SSL keys are not deleted. This > should occur if ds.protocol > 0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-514) ORT: Change Traffic Ops hostname in middle of ORT run
[
https://issues.apache.org/jira/browse/TC-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-514:
---
Affects Version/s: 2.2.0
> ORT: Change Traffic Ops hostname in middle of ORT run
> -
>
> Key: TC-514
> URL: https://issues.apache.org/jira/browse/TC-514
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops ORT
>Affects Versions: 2.1.0, 2.2.0
> Environment: Traffic Ops 2.1 and ORT 2.1
>Reporter: Steve Malenfant
>Assignee: Derek Gelinas
>Priority: Minor
> Fix For: 2.2.0
>
>
> I'm not sure if this is 2.1 specifics... Worth discussing.
> - Could this prevent load balancing traffic ops from working?
> - Cookies might be different (you need to sync secrets?). These are in the
> cdn.conf and not the database...
> When you instruct the traffic_ops_ort to go to a secondary Traffic Ops, it
> will start on the CLI designated but will move back to the primary during the
> "Start processing packages" process.
> Code in question :
> https://github.com/apache/incubator-trafficcontrol/blob/2.1.x/traffic_ops/bin/traffic_ops_ort.pl#L201
> {code:java}
> [root@edge06 ~]# /opt/ort/traffic_ops_ort.pl -dispersion=0 report DEBUG
> https://traffic-ops-0002.coxlab.net chs:w@term@rk
> Mon Aug 14 13:29:06 UTC 2017
> DEBUG OS release is EL7.
> DEBUG Script running in report mode.
> 302
> DEBUG https://traffic-ops-0002.coxlab.net/login returned HTTP 302.
> DEBUG Cookie is
> mojolicious=eyJhdXRoX2RhdGEi4iJjaHMiLCJleHBpcmVzIjoxNTAyNzMxNzQ2fQ136010205dc8d4951e2e2194b6b463eb3d141f1e.
> DEBUG YUM_OPTS: .
> DEBUG Total connections in LWP cache: 1
> INFO Traffic Ops host: https://traffic-ops-0002.coxlab.net
> ...
> INFO: Start processing packages
> DEBUG Total connections in LWP cache: 1
> INFO Traffic Ops host: https://traffic-ops-0001.coxlab.net
> DEBUG lwp_get called with /ort/psp6cdedge06/packages
> ERROR https://traffic-ops-0001.coxlab.net/ort/edge06/packages returned HTTP
> 401! Unauthorized
> ERROR result for https://traffic-ops-0001/ort/psp6cdedge06/packages is:
>
[jira] [Updated] (TC-510) cannot apply ipv6 on delivery services
[
https://issues.apache.org/jira/browse/TC-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-510:
---
Fix Version/s: 2.2.0
2.1.0
> cannot apply ipv6 on delivery services
> --
>
> Key: TC-510
> URL: https://issues.apache.org/jira/browse/TC-510
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Sean Aoyagi
>Assignee: Dylan Volz
> Fix For: 2.1.0, 2.2.0
>
>
> attempt to change ipv6 flag from ipv4 to ipv6 results in a / unable to update
> delivery service.
> on trafficops, 2.1.0-6566.3980b417.el7 Also receive following error:
> {code}Traffic Ops fatal error occurred while processing your request.
> Error at line 50 (%= field('ds.cdn_id')->select( \@{$cdns} );)
> Global symbol "$cdns" requires explicit package name at template
> delivery_service/_form.html.ep line 50. Global symbol "$profiles" requires
> explicit package name at template delivery_service/_form.html.ep line
> 375.{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-513) Traffic Ops Golang must send Whole-Content-SHA512
[ https://issues.apache.org/jira/browse/TC-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-513: --- Affects Version/s: 2.2.0 2.1.0 > Traffic Ops Golang must send Whole-Content-SHA512 > - > > Key: TC-513 > URL: https://issues.apache.org/jira/browse/TC-513 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.2.0 >Reporter: Robert Butts >Assignee: Robert Butts > Fix For: 2.1.0 > > > Once https://github.com/apache/incubator-trafficcontrol/pull/786 is merged > fixing TC-503, TO Golang must send a Whole-Content-SHA512 header, or ORT will > fail. (In fact, TO Golang fails without it, with the current MIC.) > This is necessary for a Message Integrity Check. Previously Content-Length > was used, which must not be sent under certain circumstances with HTTP/1.1. > See pull/786 and TC-503 for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-510) cannot apply ipv6 on delivery services
[
https://issues.apache.org/jira/browse/TC-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-510:
---
Affects Version/s: 2.2.0
> cannot apply ipv6 on delivery services
> --
>
> Key: TC-510
> URL: https://issues.apache.org/jira/browse/TC-510
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Sean Aoyagi
>Assignee: Dylan Volz
> Fix For: 2.1.0, 2.2.0
>
>
> attempt to change ipv6 flag from ipv4 to ipv6 results in a / unable to update
> delivery service.
> on trafficops, 2.1.0-6566.3980b417.el7 Also receive following error:
> {code}Traffic Ops fatal error occurred while processing your request.
> Error at line 50 (%= field('ds.cdn_id')->select( \@{$cdns} );)
> Global symbol "$cdns" requires explicit package name at template
> delivery_service/_form.html.ep line 50. Global symbol "$profiles" requires
> explicit package name at template delivery_service/_form.html.ep line
> 375.{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-503) Traffic Ops ORT Fails with Chunked Encoding
[ https://issues.apache.org/jira/browse/TC-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-503: --- Fix Version/s: 2.2.0 > Traffic Ops ORT Fails with Chunked Encoding > --- > > Key: TC-503 > URL: https://issues.apache.org/jira/browse/TC-503 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops ORT >Affects Versions: 2.1.0, 2.2.0 >Reporter: Robert Butts >Assignee: Dewayne Richardson > Fix For: 2.1.0, 2.2.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > ORT fails if no 'Content-Length' header exists. > Content-Length MAY be omitted per HTTP/1.1 RFC 7230, and in fact MUST NOT be > included with a 'Transfer-Encoding: Chunked' header, which MUST be accepted > by clients. > So far, we've just been lucky Perl/Mojolicious Traffic Ops doesn't happen to > send Chunked encodings to ORT. But the spec requires clients accept it, ORT > is in violation of HTTP/1.1. > Further, the upcoming Golang Traffic Ops sends Chunked encoding, and there's > no reasonable way in Go to prevent it. There's no HTTP-compliant way to > instruct the server not to send Chunked encoding either, since clients are > required to accept it. The right solution here is to fix ORT to accept > Chunked encoding, without Content-Length. > It appears ORT only refuses it as a safety check, and doesn't actually need > it for anything. Should be a simple fix. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-503) Traffic Ops ORT Fails with Chunked Encoding
[ https://issues.apache.org/jira/browse/TC-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-503: --- Affects Version/s: 2.2.0 > Traffic Ops ORT Fails with Chunked Encoding > --- > > Key: TC-503 > URL: https://issues.apache.org/jira/browse/TC-503 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops ORT >Affects Versions: 2.1.0, 2.2.0 >Reporter: Robert Butts >Assignee: Dewayne Richardson > Fix For: 2.1.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > ORT fails if no 'Content-Length' header exists. > Content-Length MAY be omitted per HTTP/1.1 RFC 7230, and in fact MUST NOT be > included with a 'Transfer-Encoding: Chunked' header, which MUST be accepted > by clients. > So far, we've just been lucky Perl/Mojolicious Traffic Ops doesn't happen to > send Chunked encodings to ORT. But the spec requires clients accept it, ORT > is in violation of HTTP/1.1. > Further, the upcoming Golang Traffic Ops sends Chunked encoding, and there's > no reasonable way in Go to prevent it. There's no HTTP-compliant way to > instruct the server not to send Chunked encoding either, since clients are > required to accept it. The right solution here is to fix ORT to accept > Chunked encoding, without Content-Length. > It appears ORT only refuses it as a safety check, and doesn't actually need > it for anything. Should be a simple fix. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-494) Clone DS assignments button on Server times out
[ https://issues.apache.org/jira/browse/TC-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-494: --- Fix Version/s: 2.2.0 2.1.0 > Clone DS assignments button on Server times out > --- > > Key: TC-494 > URL: https://issues.apache.org/jira/browse/TC-494 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Matt Mills >Assignee: Dylan Volz > Fix For: 2.1.0, 2.2.0 > > > When you try to clone DS assignments in our current production environment, > it will never complete the "clone" process, and gets timed out midway > through, leaving you with a broken configuration on that server. -- 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
[ https://issues.apache.org/jira/browse/TC-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-500: --- Affects Version/s: 2.2.0 > 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, 2.2.0 >Reporter: Robert Scrimo >Priority: Minor > Fix For: 2.2.0 > > > 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] [Updated] (TC-500) Creating/Updating a Delivery Service via API has length constraint on displayName of 48, but no such constraint in UI code
[ https://issues.apache.org/jira/browse/TC-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-500: --- Fix Version/s: 2.2.0 > 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, 2.2.0 >Reporter: Robert Scrimo >Priority: Minor > Fix For: 2.2.0 > > > 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] [Updated] (TC-492) Deleting Delivery Service with associated static dns entry(s) in staticdnsentry table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-492: --- Affects Version/s: 2.2.0 > Deleting Delivery Service with associated static dns entry(s) in > staticdnsentry table fails due to foreign key constraint violation > --- > > Key: TC-492 > URL: https://issues.apache.org/jira/browse/TC-492 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > Fix For: 2.1.0, 2.2.0 > > > Deleting Delivery Service with associated static dns entry in staticdnsentry > table fails due to foreign key constraint violation. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_staticdnsentry_ds" on table "staticdnsentry" > DETAIL: Key (id)=(180) is still referenced from table "staticdnsentry". [for > Statement "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: > 1='180'] at /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: Use the UI to remove the association(s) before deleting the > delivery service. > NOTE: Other versions of Traffic Ops may be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-492) Deleting Delivery Service with associated static dns entry(s) in staticdnsentry table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-492: --- Fix Version/s: 2.2.0 2.1.0 > Deleting Delivery Service with associated static dns entry(s) in > staticdnsentry table fails due to foreign key constraint violation > --- > > Key: TC-492 > URL: https://issues.apache.org/jira/browse/TC-492 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > Fix For: 2.1.0, 2.2.0 > > > Deleting Delivery Service with associated static dns entry in staticdnsentry > table fails due to foreign key constraint violation. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_staticdnsentry_ds" on table "staticdnsentry" > DETAIL: Key (id)=(180) is still referenced from table "staticdnsentry". [for > Statement "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: > 1='180'] at /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: Use the UI to remove the association(s) before deleting the > delivery service. > NOTE: Other versions of Traffic Ops may be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-491) Deleting Delivery Service with associated job in job table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-491: --- Fix Version/s: 2.2.0 2.1.0 > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation > > > Key: TC-491 > URL: https://issues.apache.org/jira/browse/TC-491 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > Fix For: 2.1.0, 2.2.0 > > > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation. > E.g. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_job_deliveryservice1" on table "job" > DETAIL: Key (id)=(714) is still referenced from table "job". [for Statement > "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: 1='714'] at > /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: No UI/API end-point to delete the associated job. Delete > associated job from database. > NOTE: Other Traffic Ops versions may also be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-490) mso.qstring_handling parameter is checked but not documented
[
https://issues.apache.org/jira/browse/TC-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-490:
---
Affects Version/s: 2.2.0
> 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, 2.2.0
>Reporter: Matt Mills
>Priority: Blocker
> Fix For: 2.1.0, 2.2.0
>
>
> 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-491) Deleting Delivery Service with associated job in job table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-491: --- Affects Version/s: 2.2.0 > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation > > > Key: TC-491 > URL: https://issues.apache.org/jira/browse/TC-491 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation. > E.g. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_job_deliveryservice1" on table "job" > DETAIL: Key (id)=(714) is still referenced from table "job". [for Statement > "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: 1='714'] at > /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: No UI/API end-point to delete the associated job. Delete > associated job from database. > NOTE: Other Traffic Ops versions may also be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-489) Multi Site Origin - Invalid default values for multiple config params
[
https://issues.apache.org/jira/browse/TC-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-489:
---
Affects Version/s: 2.2.0
> Multi Site Origin - Invalid default values for multiple config params
> -
>
> Key: TC-489
> URL: https://issues.apache.org/jira/browse/TC-489
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Matt Mills
>Priority: Blocker
> Fix For: 2.1.0, 2.2.0
>
>
> Several of the multi site origin parameters default to 0 (including
> mso.algorithm, possibly others ), which is an invalid argument.
>valid values: true, strict, proxy1, false, consistent_hash
>
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Configs/ApacheTrafficServer.pm#L2051
> {code}
>L2051: $text .= "$parents round_robin=$mso_algorithm
> qstring=$parent_qstring go_direct=false parent_is_proxy=false";
> {code}
> {code}
>parent.config: dest_domain=google.com port=443 ... round_robin=0 ...
> {code}
> {code}
>[Jul 12 02:25:45.987] Server {0x2b54fb7db940} ERROR: [ParentSelection]
> invalid argument to round_robin directive at line 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-488) Docs - Multi Site Origin not up to date
[ https://issues.apache.org/jira/browse/TC-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-488: --- Fix Version/s: 2.2.0 2.1.0 > Docs - Multi Site Origin not up to date > --- > > Key: TC-488 > URL: https://issues.apache.org/jira/browse/TC-488 > Project: Traffic Control > Issue Type: Bug > Components: Documentation >Affects Versions: 2.1.0, 2.2.0 >Reporter: Matt Mills >Priority: Blocker > Fix For: 2.1.0, 2.2.0 > > > Current documentation for multi site origin is confusing/wrong/out of date: > > https://github.com/apache/incubator-trafficcontrol/blob/master/docs/source/admin/quick_howto/multi_site.rst >Bottom has steps that references configuration that I think has been > replaced with delivery service profiles. > > https://github.com/apache/incubator-trafficcontrol/blob/master/docs/source/admin/traffic_ops/using.rst >mentions the new delivery service profile pieces, but not the cachegroup > side of multi-site configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-489) Multi Site Origin - Invalid default values for multiple config params
[
https://issues.apache.org/jira/browse/TC-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-489:
---
Fix Version/s: 2.2.0
2.1.0
> Multi Site Origin - Invalid default values for multiple config params
> -
>
> Key: TC-489
> URL: https://issues.apache.org/jira/browse/TC-489
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Matt Mills
>Priority: Blocker
> Fix For: 2.1.0, 2.2.0
>
>
> Several of the multi site origin parameters default to 0 (including
> mso.algorithm, possibly others ), which is an invalid argument.
>valid values: true, strict, proxy1, false, consistent_hash
>
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Configs/ApacheTrafficServer.pm#L2051
> {code}
>L2051: $text .= "$parents round_robin=$mso_algorithm
> qstring=$parent_qstring go_direct=false parent_is_proxy=false";
> {code}
> {code}
>parent.config: dest_domain=google.com port=443 ... round_robin=0 ...
> {code}
> {code}
>[Jul 12 02:25:45.987] Server {0x2b54fb7db940} ERROR: [ParentSelection]
> invalid argument to round_robin directive at line 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-488) Docs - Multi Site Origin not up to date
[ https://issues.apache.org/jira/browse/TC-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-488: --- Affects Version/s: 2.2.0 > Docs - Multi Site Origin not up to date > --- > > Key: TC-488 > URL: https://issues.apache.org/jira/browse/TC-488 > Project: Traffic Control > Issue Type: Bug > Components: Documentation >Affects Versions: 2.1.0, 2.2.0 >Reporter: Matt Mills >Priority: Blocker > Fix For: 2.1.0, 2.2.0 > > > Current documentation for multi site origin is confusing/wrong/out of date: > > https://github.com/apache/incubator-trafficcontrol/blob/master/docs/source/admin/quick_howto/multi_site.rst >Bottom has steps that references configuration that I think has been > replaced with delivery service profiles. > > https://github.com/apache/incubator-trafficcontrol/blob/master/docs/source/admin/traffic_ops/using.rst >mentions the new delivery service profile pieces, but not the cachegroup > side of multi-site configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-487) Multi Site Origin config gets applied even when no valid parents
[
https://issues.apache.org/jira/browse/TC-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-487:
---
Affects Version/s: 2.2.0
> Multi Site Origin config gets applied even when no valid parents
>
>
> Key: TC-487
> URL: https://issues.apache.org/jira/browse/TC-487
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Matt Mills
>Priority: Minor
> Fix For: 2.2.0
>
>
> If MSO is not properly configured with origin servers but is configured with
> multi site origin, it will install the multi site origin parent.config with
> no parent servers listed.
>(Mine had the origin servers in a non ORG type cache group, this generated
> parent="" in the config)
>parent.config: dest_domain=google.com port=443 parent="" ...
>Jul 12 01:26:46 lab-ats-mid-2.local traffic_server[3916]: {0x2ae9206f1940}
> ERROR: [ParentSelection] No parents specified at line 2
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-487) Multi Site Origin config gets applied even when no valid parents
[
https://issues.apache.org/jira/browse/TC-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-487:
---
Fix Version/s: 2.2.0
> Multi Site Origin config gets applied even when no valid parents
>
>
> Key: TC-487
> URL: https://issues.apache.org/jira/browse/TC-487
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Matt Mills
>Priority: Minor
> Fix For: 2.2.0
>
>
> If MSO is not properly configured with origin servers but is configured with
> multi site origin, it will install the multi site origin parent.config with
> no parent servers listed.
>(Mine had the origin servers in a non ORG type cache group, this generated
> parent="" in the config)
>parent.config: dest_domain=google.com port=443 parent="" ...
>Jul 12 01:26:46 lab-ats-mid-2.local traffic_server[3916]: {0x2ae9206f1940}
> ERROR: [ParentSelection] No parents specified at line 2
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-472) traffic_ops/experimental - failure to assign servers to new Delivery Service
[ https://issues.apache.org/jira/browse/TC-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-472: --- Affects Version/s: 2.2.0 > traffic_ops/experimental - failure to assign servers to new Delivery Service > > > Key: TC-472 > URL: https://issues.apache.org/jira/browse/TC-472 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jason Tucker >Priority: Minor > Fix For: 2.2.0 > > > While using the new UI, I was unable to assign servers to a newly-created DS. > After submitting the change, no servers were linked. No error apparent when > submitting. Tried multiple times with same results. > Browser: chrome 58.0.3029.110 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-472) traffic_ops/experimental - failure to assign servers to new Delivery Service
[ https://issues.apache.org/jira/browse/TC-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-472: --- Fix Version/s: 2.2.0 > traffic_ops/experimental - failure to assign servers to new Delivery Service > > > Key: TC-472 > URL: https://issues.apache.org/jira/browse/TC-472 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jason Tucker >Priority: Minor > Fix For: 2.2.0 > > > While using the new UI, I was unable to assign servers to a newly-created DS. > After submitting the change, no servers were linked. No error apparent when > submitting. Tried multiple times with same results. > Browser: chrome 58.0.3029.110 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-418) getting displayName too long using API but UI has no issue
[
https://issues.apache.org/jira/browse/TC-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-418:
---
Fix Version/s: 2.2.0
> getting displayName too long using API but UI has no issue
> --
>
> Key: TC-418
> URL: https://issues.apache.org/jira/browse/TC-418
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0, 2.2.0
> Environment: API
>Reporter: Joseph Pappano
>Priority: Minor
> Fix For: 2.2.0
>
>
> Here is the API out put with the error
> {code}
> {'active': True,
> 'cacheurl': None,
> 'ccrDnsTtl': 3600,
> 'cdnId': 2,
> 'cdnName': u'title-vi',
> 'checkPath': u'crossdomain.xml',
> 'displayName': u'Title VI Linear - Florida-Jacksonville from CMC stack',
> 'dnsBypassCname': None,
> 'dnsBypassIp': None,
> 'dnsBypassIp6': None,
> 'dnsBypassTtl': 30,
> 'dscp': 40,
> 'edgeHeaderRewrite': None,
> 'geoLimit': 0,
> 'geoLimitCountries': u'',
> 'geoLimitRedirectURL': u'',
> 'geoProvider': 0,
> 'globalMaxMbps': None,
> 'globalMaxTps': 0,
> 'httpBypassFqdn': u'',
> 'infoUrl': u'https://tkts.sys.comcast.net/browse/CDNOPS-3176',
> 'initialDispersion': 1,
> 'ipv6RoutingEnabled': True,
> 'logsEnabled': False,
> 'longDesc': u'Title VI Linear - Florida-Jacksonville from Redundant stack in
> CMC',
> 'longDesc1': None,
> 'longDesc2': u'linear-cmc-jksnv-fl-pil',
> 'maxDnsAnswers': 0,
> 'midHeaderRewrite': None,
> 'missLat': 41.881944,
> 'missLong': -87.627778,
> 'multiSiteOrigin': False,
> 'orgServerFqdn': u'http://rlr-cmc-slivel4lb-vip.cmc.co.ndcwest.comcast.net',
> 'originShield': None,
> 'profileDescription': None,
> 'profileId': None,
> 'profileName': None,
> 'protocol': 2,
> 'qstringIgnore': 1,
> 'rangeRequestHandling': 0,
> 'regexRemap': None,
> 'regionalGeoBlocking': False,
> 'remapText': None,
> 'signed': False,
> 'trRequestHeaders': 'X-MoneyTrace',
> 'trResponseHeaders': None,
> 'typeId': 13,
> 'xmlId': u'linear-cmc-jksnv-fl-pil'}
> {u'alerts': [{u'level': u'error', u'text': u'displayName too long'}]}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-418) getting displayName too long using API but UI has no issue
[
https://issues.apache.org/jira/browse/TC-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-418:
---
Affects Version/s: 2.2.0
> getting displayName too long using API but UI has no issue
> --
>
> Key: TC-418
> URL: https://issues.apache.org/jira/browse/TC-418
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0, 2.2.0
> Environment: API
>Reporter: Joseph Pappano
>Priority: Minor
> Fix For: 2.2.0
>
>
> Here is the API out put with the error
> {code}
> {'active': True,
> 'cacheurl': None,
> 'ccrDnsTtl': 3600,
> 'cdnId': 2,
> 'cdnName': u'title-vi',
> 'checkPath': u'crossdomain.xml',
> 'displayName': u'Title VI Linear - Florida-Jacksonville from CMC stack',
> 'dnsBypassCname': None,
> 'dnsBypassIp': None,
> 'dnsBypassIp6': None,
> 'dnsBypassTtl': 30,
> 'dscp': 40,
> 'edgeHeaderRewrite': None,
> 'geoLimit': 0,
> 'geoLimitCountries': u'',
> 'geoLimitRedirectURL': u'',
> 'geoProvider': 0,
> 'globalMaxMbps': None,
> 'globalMaxTps': 0,
> 'httpBypassFqdn': u'',
> 'infoUrl': u'https://tkts.sys.comcast.net/browse/CDNOPS-3176',
> 'initialDispersion': 1,
> 'ipv6RoutingEnabled': True,
> 'logsEnabled': False,
> 'longDesc': u'Title VI Linear - Florida-Jacksonville from Redundant stack in
> CMC',
> 'longDesc1': None,
> 'longDesc2': u'linear-cmc-jksnv-fl-pil',
> 'maxDnsAnswers': 0,
> 'midHeaderRewrite': None,
> 'missLat': 41.881944,
> 'missLong': -87.627778,
> 'multiSiteOrigin': False,
> 'orgServerFqdn': u'http://rlr-cmc-slivel4lb-vip.cmc.co.ndcwest.comcast.net',
> 'originShield': None,
> 'profileDescription': None,
> 'profileId': None,
> 'profileName': None,
> 'protocol': 2,
> 'qstringIgnore': 1,
> 'rangeRequestHandling': 0,
> 'regexRemap': None,
> 'regionalGeoBlocking': False,
> 'remapText': None,
> 'signed': False,
> 'trRequestHeaders': 'X-MoneyTrace',
> 'trResponseHeaders': None,
> 'typeId': 13,
> 'xmlId': u'linear-cmc-jksnv-fl-pil'}
> {u'alerts': [{u'level': u'error', u'text': u'displayName too long'}]}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-426) Postinstall -- answering "no" to certificate generation does not skip
[ https://issues.apache.org/jira/browse/TC-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-426: --- Fix Version/s: 2.2.0 > Postinstall -- answering "no" to certificate generation does not skip > - > > Key: TC-426 > URL: https://issues.apache.org/jira/browse/TC-426 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.2.0 >Reporter: Dewayne Richardson >Priority: Minor > Fix For: 2.2.0 > > > Answering 'no' to 'Do you want to generate a certificate?:' forces > certificate generation. That section should have been skipped. > ===/opt/traffic_ops/install/data/json/openssl_configuration.json=== > Do you want to generate a certificate?: no > Country Name (2 letter code): US -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-426) Postinstall -- answering "no" to certificate generation does not skip
[ https://issues.apache.org/jira/browse/TC-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-426: --- Affects Version/s: 2.2.0 > Postinstall -- answering "no" to certificate generation does not skip > - > > Key: TC-426 > URL: https://issues.apache.org/jira/browse/TC-426 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.2.0 >Reporter: Dewayne Richardson >Priority: Minor > Fix For: 2.2.0 > > > Answering 'no' to 'Do you want to generate a certificate?:' forces > certificate generation. That section should have been skipped. > ===/opt/traffic_ops/install/data/json/openssl_configuration.json=== > Do you want to generate a certificate?: no > Country Name (2 letter code): US -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-413) Mid header rewrite in Traffic Ops breaks if mid cache profile changed
[ https://issues.apache.org/jira/browse/TC-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-413: --- Fix Version/s: 2.2.0 > Mid header rewrite in Traffic Ops breaks if mid cache profile changed > - > > Key: TC-413 > URL: https://issues.apache.org/jira/browse/TC-413 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 1.7.0 >Reporter: Mike Sandman >Priority: Minor > Fix For: 2.2.0 > > > If you have mid header rewrite rules set for a DS, when you configure the > rule it adds a config file "location" to the Parameters table associated with > that mid profile. If you change the mid profile afterwards, the "location" > parameter is not moved, and so mid header rewrite breaks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-407) Cannot update a steering type delivery service via API
[
https://issues.apache.org/jira/browse/TC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-407:
---
Fix Version/s: 2.2.0
2.1.0
> 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, 2.2.0
>Reporter: Joseph Pappano
>Assignee: Jeremy Mitchell
> Fix For: 2.1.0, 2.2.0
>
>
> 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] [Updated] (TC-408) Documentation for creating ssl keys is missing a field.
[
https://issues.apache.org/jira/browse/TC-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-408:
---
Fix Version/s: 2.2.0
2.1.0
> Documentation for creating ssl keys is missing a field.
> ---
>
> Key: TC-408
> URL: https://issues.apache.org/jira/browse/TC-408
> Project: Traffic Control
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Joseph Pappano
>Priority: Minor
> Fix For: 2.1.0, 2.2.0
>
>
> The documentation to generate ssl keys is missing the delivery service field.
> generating keys with that field being null will cause issues on Riak.
> {code}
> POST /api/1.2/deliveryservices/sslkeys/generate
> Generates SSL crt, csr, and private key for a delivery service
> Authentication Required: Yes
> Role(s) Required: Admin
> Request Properties
> Parameter TypeDescription
> key string xml_id of the delivery service
> version string version of the keys being generated
> hostname string the pristine hostname of the delivery service
> country string
> state string
> city string
> org string
> unit boolean
> Request Example
> {
> "key": "ds-01",
> "businessUnit": "CDN Engineering",
> "version": "3",
> "hostname": "tr.ds-01.ott.kabletown.com",
> "certificate": {
> "key": "some_key",
> "csr": "some_csr",
> "crt": "some_crt"
> },
> "country": "US",
> "organization": "Kabletown",
> "city": "Denver",
> "state": "Colorado"
> }{code}
> These are the fields required. Notice the delivery service is null.
> {code}
> {
> "cdn": null,
> "certificate": {
> "crt":
> "csr": "key": },
> "city": "Denver",
> "country": "US",
> "deliveryservice": null,
> "hostname": "*.linear-chi-pil-red.xcr.comcast.net",
> "key": "linear-chi-pil-red",
> "org": null,
> "state": "Colorado",
> "unit": "IPCDN",
> "version": "1"
> }{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TC-407) Cannot update a steering type delivery service via API
[
https://issues.apache.org/jira/browse/TC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16129060#comment-16129060
]
Hank Beatty commented on TC-407:
[~jpappa200] Please Jeremy's comments above. Will close this issue in 3 days if
no response.
> 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, 2.2.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] [Updated] (TC-407) Cannot update a steering type delivery service via API
[
https://issues.apache.org/jira/browse/TC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-407:
---
Affects Version/s: 2.2.0
> 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, 2.2.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] [Assigned] (TC-397) Traffic Stats install can't create traffic_stats user
[
https://issues.apache.org/jira/browse/TC-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty reassigned TC-397:
--
Assignee: Hank Beatty
> Traffic Stats install can't create traffic_stats user
> -
>
> Key: TC-397
> URL: https://issues.apache.org/jira/browse/TC-397
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Stats
>Affects Versions: 2.0.0
>Reporter: David Neuman
>Assignee: Hank Beatty
>Priority: Minor
> Fix For: 2.1.0, 2.2.0
>
>
> The traffic_stats install throws errors saying that it cannot create the
> traffic_stats user. The result is that everything is owned by root instead.
> The install process should make the necessary user:
> {quote}
> Running transaction
> groupadd: GID '422' already exists
> useradd: group 'traffic_stats' does not exist
> passwd: Unknown user name 'traffic_stats'.
> chage: user 'traffic_stats' does not exist in /etc/passwd
> Installing : traffic_stats-2.0.0-5668.85d14ebe.el7.x86_64
>
>
>
> 1/1
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-397) Traffic Stats install can't create traffic_stats user
[
https://issues.apache.org/jira/browse/TC-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-397:
---
Fix Version/s: 2.2.0
2.1.0
> Traffic Stats install can't create traffic_stats user
> -
>
> Key: TC-397
> URL: https://issues.apache.org/jira/browse/TC-397
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Stats
>Affects Versions: 2.0.0
>Reporter: David Neuman
>Priority: Minor
> Fix For: 2.1.0, 2.2.0
>
>
> The traffic_stats install throws errors saying that it cannot create the
> traffic_stats user. The result is that everything is owned by root instead.
> The install process should make the necessary user:
> {quote}
> Running transaction
> groupadd: GID '422' already exists
> useradd: group 'traffic_stats' does not exist
> passwd: Unknown user name 'traffic_stats'.
> chage: user 'traffic_stats' does not exist in /etc/passwd
> Installing : traffic_stats-2.0.0-5668.85d14ebe.el7.x86_64
>
>
>
> 1/1
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> warning: user traffic_stats does not exist - using root
> warning: group traffic_stats does not exist - using root
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-385) IPv6 Origin Configuration Not Allowed
[ https://issues.apache.org/jira/browse/TC-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-385: --- Fix Version/s: 2.2.0 2.1.0 > IPv6 Origin Configuration Not Allowed > - > > Key: TC-385 > URL: https://issues.apache.org/jira/browse/TC-385 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Zhilin Huang >Assignee: Zhilin Huang > Labels: ipv6, origin > Fix For: 2.1.0, 2.2.0 > > > IPv6 origins need to be configured using brackets if using the IP (such as > http://[fec0::250:56ff:fea9:172]), but Traffic Ops rejects it with error: > [fec0 is not a valid org server name (rfc1123) or :250:56ff:fea9:172] is not > a valid port -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-373) Traffic Stats Has Connection Leak
[ https://issues.apache.org/jira/browse/TC-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-373: --- Fix Version/s: 2.2.0 2.1.0 > Traffic Stats Has Connection Leak > -- > > Key: TC-373 > URL: https://issues.apache.org/jira/browse/TC-373 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Stats >Reporter: Zhilin Huang >Assignee: Zhilin Huang > Labels: connections > Fix For: 2.1.0, 2.2.0 > > > Happens when TO not response 200 OK to traffic stats: > [ERROR] 2017-06-08 09:54:40 500 Internal Server Error[500] - Error requesting > Traffic Ops https://coffee-ops-a.coffee.com/api/1.2/stats_summary/create > $ sudo netstat -tunp|grep traffic_stats|head > tcp 32 0 10.63.115.225:39667 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats > tcp 32 0 10.63.115.225:50388 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats > tcp 32 0 10.63.115.225:46896 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats > tcp 32 0 10.63.115.225:38896 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats > tcp1 0 10.63.115.225:53682 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats > tcp 32 0 10.63.115.225:42324 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats > tcp 32 0 10.63.115.225:39618 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats > tcp 32 0 10.63.115.225:36613 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats > tcp 32 0 10.63.115.225:51851 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats > tcp 32 0 10.63.115.225:52842 10.63.115.224:443 > CLOSE_WAIT 795/traffic_stats -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-374) `systemctl stop traffic_ops` does not kill all processes
[
https://issues.apache.org/jira/browse/TC-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-374:
---
Fix Version/s: 2.2.0
> `systemctl stop traffic_ops` does not kill all processes
>
>
> Key: TC-374
> URL: https://issues.apache.org/jira/browse/TC-374
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
> Labels: systemctl
> Fix For: 2.1.0, 2.2.0
>
>
> not sure why it gets in this state, but traffic_ops processes sometimes get
> in a state where the parent process is the root (1) for many of the
> script/cdn workers. The init.d script doesn't stop them because they don't
> match the pid in `/var/run/traffic_ops.pid`.
> This needs to be more robust.
> Example: on my test VM, if I run this, I see multiple parent processes:
> {quote}
> ps -ef | grep script/cdn|grep -v root | awk '\{print $3\}' | sort -u
> 1
> 22713
> 29306
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-377) Default profiles for EDGE and MID are missing after initial install
[ https://issues.apache.org/jira/browse/TC-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-377: --- Fix Version/s: 2.2.0 > Default profiles for EDGE and MID are missing after initial install > --- > > Key: TC-377 > URL: https://issues.apache.org/jira/browse/TC-377 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Jan van Doorn >Assignee: Jan van Doorn > Labels: profiles > Fix For: 2.1.0, 2.2.0 > > > I suggest we don't add these to the seeds, but create a "profile exchange" > that people can dl the right profile from. > I'll take a first stab at this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-369) ORT recreates certain files on each run.
[ https://issues.apache.org/jira/browse/TC-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty closed TC-369. -- Resolution: Fixed already merged. > ORT recreates certain files on each run. > > > Key: TC-369 > URL: https://issues.apache.org/jira/browse/TC-369 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops ORT >Affects Versions: 2.1.0 >Reporter: Joseph Pappano >Assignee: Derek Gelinas >Priority: Minor > Labels: parent.config > > each time ORT runs there will be subtle differences in parent.config and > other files and they are needlessly recreated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-368) api/1.2/deliveryservices/:id/routing.json hangs when Traffic Router is unreachable
[ https://issues.apache.org/jira/browse/TC-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-368: --- Fix Version/s: 2.1.0 > api/1.2/deliveryservices/:id/routing.json hangs when Traffic Router is > unreachable > -- > > Key: TC-368 > URL: https://issues.apache.org/jira/browse/TC-368 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 1.8.0 >Reporter: Steve Malenfant > Labels: api_deliveryservices, routing > Fix For: 2.1.0 > > > I was testing this API "/api/1.2/deliveryservices/:id/routing.json" and found > that it would hang and the perl worker had to be killled. This caused 500 > Errors back from TO API. > The root cause is Traffic Router not responding to API Port. > We should not poll Traffic Router that are status=OFFLINE and there should be > some sort of timeouts in place to make sure it doesn't take more than x > seconds to return information from API > There is some comments in the code that seems to indication prior issues. > `# TODO: what happens when the request to CCR times out?` -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-367) Download page must not link to dist.apache.org
[ https://issues.apache.org/jira/browse/TC-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-367: --- Fix Version/s: 2.2.0 2.1.0 > Download page must not link to dist.apache.org > -- > > Key: TC-367 > URL: https://issues.apache.org/jira/browse/TC-367 > Project: Traffic Control > Issue Type: Bug > Components: Documentation >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Sebb >Assignee: Hank Beatty > Labels: documentation, links > Fix For: 2.1.0, 2.2.0 > > > The dist.apache.org SVN area is only intended as the staging area for the ASF > mirror service. > Please do not link to files on it from download pages. > Sigs and hashes should link to: > https://www.apache.org/dist/incubator/trafficcontrol/ > instead. And later to > https://www.apache.org/dist/trafficcontrol/ > Also the download page needs an https link to the KEYS file > https://www.apache.org/dist/incubator/trafficcontrol/KEYS > and some instructions on how to check sigs or hashes. > Please see: > http://www.apache.org/dev/release-publishing.html#distribution_dist -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-363) cacheurl_qstring.conf file is not generated when qstringIgnore=1 and location profile parameter is missing for edge/mid cache
[
https://issues.apache.org/jira/browse/TC-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-363:
---
Fix Version/s: 2.1.0
> cacheurl_qstring.conf file is not generated when qstringIgnore=1 and location
> profile parameter is missing for edge/mid cache
> -
>
> Key: TC-363
> URL: https://issues.apache.org/jira/browse/TC-363
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Robert Scrimo
> Labels: Configuration, cacheurl_qstring.conf
> Fix For: 2.1.0
>
>
> {{cacheurl_qstring.conf}} file is not generated when {{qstringIgnore=1}} and
> {{location}} profile parameter for config file {{cacheurl_qstring.config}} is
> missing for edge/mid cache profile. This is a issue because {{remap.config}}
> references this non-existent file.
> {quote}
> e.g. map http://edge-cache.http-ds.mycdn.somedomain.com/
> http://origin-server.somedomain.com/ @plugin=header_rewrite.so
> @pparam=dscp/set_dscp_0.config @plugin=cacheurl.so
> @pparam=cacheurl_qstring.config
> {quote}
> The workaround is to add {{location}} parameter for
> {{cacheurl_qstring.config}} config file to the edge/mid cache profile.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-367) Download page must not link to dist.apache.org
[ https://issues.apache.org/jira/browse/TC-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-367: --- Affects Version/s: 2.2.0 2.0.0 2.1.0 > Download page must not link to dist.apache.org > -- > > Key: TC-367 > URL: https://issues.apache.org/jira/browse/TC-367 > Project: Traffic Control > Issue Type: Bug > Components: Documentation >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Sebb >Assignee: Hank Beatty > Labels: documentation, links > Fix For: 2.1.0, 2.2.0 > > > The dist.apache.org SVN area is only intended as the staging area for the ASF > mirror service. > Please do not link to files on it from download pages. > Sigs and hashes should link to: > https://www.apache.org/dist/incubator/trafficcontrol/ > instead. And later to > https://www.apache.org/dist/trafficcontrol/ > Also the download page needs an https link to the KEYS file > https://www.apache.org/dist/incubator/trafficcontrol/KEYS > and some instructions on how to check sigs or hashes. > Please see: > http://www.apache.org/dev/release-publishing.html#distribution_dist -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-360) astats IPv6 and IPv4 access list behavior inconsistency
[
https://issues.apache.org/jira/browse/TC-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-360:
---
Fix Version/s: 2.2.0
> astats IPv6 and IPv4 access list behavior inconsistency
> ---
>
> Key: TC-360
> URL: https://issues.apache.org/jira/browse/TC-360
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Server Plugins
>Affects Versions: 2.0.0
>Reporter: Jeff Elsloo
>Priority: Minor
> Labels: allow_ip, allow_ip6, astats
> Fix For: 2.2.0
>
>
> The behavior of the access configuration parameter for astats is
> inconsistent. When {{allow_ip}} is present with no arguments, or is missing,
> requests into astats are denied with a 404 not found. The {{allow_ip6}}
> parameter is the opposite. When present with no arguments, or missing,
> requests into astats are served. When an IP list is present in either case,
> access is denied unless one's source address is within the specified list of
> subnets.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-353) Can't use CNAME hostname with "ccr" prefix
[
https://issues.apache.org/jira/browse/TC-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-353:
---
Fix Version/s: 2.2.0
2.1.0
> Can't use CNAME hostname with "ccr" prefix
> --
>
> Key: TC-353
> URL: https://issues.apache.org/jira/browse/TC-353
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0, 2.0.0, 1.8.0
>Reporter: Steve Malenfant
>Priority: Minor
> Labels: cname, configuration, host_regex
> Fix For: 2.1.0, 2.2.0
>
>
> If you put a HOST_REGEX of "ccr.example.kabletown.net", it will expand to the
> server hostname like "edge01.example.kabletown.net". This makes the
> remap.config to have the wrong hostname. This might not affect anything but
> it should be changed to something unrelated to a specific prefix.
> The code ConfigFile.pm is causing the current behavior :
> {code}
> my $hname = $ds_type =~ /^DNS/ ? "edge" : "ccr";
> my $portstr = "";
> ...
> $map_from =~ s/ccr/$host_name/;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-351) Generate new SSL keys fails after a while
[
https://issues.apache.org/jira/browse/TC-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-351:
---
Fix Version/s: 2.2.0
> Generate new SSL keys fails after a while
> -
>
> Key: TC-351
> URL: https://issues.apache.org/jira/browse/TC-351
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 1.8.0
> Environment: Traffic Ops 1.8
> openssl-1.0.1e
>Reporter: Steve Malenfant
>Priority: Minor
> Labels: ssl
> Fix For: 2.2.0
>
>
> After some Traffic Ops runtime (few days), we noticed that we can't generate
> certificate anymore and receiving these messages in the log:
> {code}
> [2017-05-23 12:32:11,175] [DEBUG] Routing to controller "UI::SslKeys" and
> action "create".
> [2017-05-23 12:32:11,572] [WARN] SSL keys for 'test_deliveryservice' could
> not be created. Response was Error creating key and csr. Result is -1
> [2017-05-23 12:32:11,573] [DEBUG] 302 Found (0.399329s, 2.504/s).
> {code}
> The CSR and KEY is created and valid in /var/tmp.
> Issuing a "service traffic_ops restart" fixes the issue.
> The code which seems to be failing is here :
> {code}
> #generate key and csr
> my $result = UI::Utils->exec_command(
> "openssl req -nodes -newkey rsa:2048 -keyout
> $TMP_LOCATION/$hostname.key -out $TMP_LOCATION/$hostname.csr -subj
> /C=\"$country\"/ST=\"$state\"/L=\"$city\"/O=\"$org\"/OU=\"$unit\"/CN=$hostname"
> );
> if ( $result != 0 ) {
> $response = { _rc => 400, _content => "Error
> creating key and csr. Result is $result" };
> return $response;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-339) Traffic Router should not bring unresponsive Traffic Monitor decisions back right away
[ https://issues.apache.org/jira/browse/TC-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-339: --- Issue Type: Improvement (was: Bug) > Traffic Router should not bring unresponsive Traffic Monitor decisions back > right away > -- > > Key: TC-339 > URL: https://issues.apache.org/jira/browse/TC-339 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Router >Reporter: Zhilin Huang > Labels: health_monitoring > > Traffic Monitor split-brain scenario can have a violent recovery path -- > potentially taking marking all caches unhealthy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-337) Inactive delivery services are added to remap.config
[ https://issues.apache.org/jira/browse/TC-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-337: --- Fix Version/s: 2.1.0 > Inactive delivery services are added to remap.config > > > Key: TC-337 > URL: https://issues.apache.org/jira/browse/TC-337 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Nir Sopher >Assignee: Derek Gelinas > Labels: remap.config > Fix For: 2.1.0 > > > Based on: https://github.com/Comcast/traffic_control/issues/1287 > Some (maybe all) inactive delivery services (at least ANY_MAP) are added to > remap.config. Inactive delivery services should not be in remap.config or any > config for that matter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-327) ConfigFiles.pm detects blank as not null and tries to gen files GH #1090
[ https://issues.apache.org/jira/browse/TC-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-327: --- Fix Version/s: 2.1.0 > ConfigFiles.pm detects blank as not null and tries to gen files GH #1090 > > > Key: TC-327 > URL: https://issues.apache.org/jira/browse/TC-327 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Dewayne Richardson >Assignee: Derek Gelinas > Labels: configfiles.pm, configuration > Fix For: 2.1.0 > > > ConfigFiles.pm will read a blank in the database as a file that needs > creation or action upon. Some defensive code should detect this issue and > either treat it as a null or pitch an error with some troubleshooting steps > to fix the issue. > https://github.com/Comcast/traffic_control/issues/1090 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-320) cache url config parameters not created at the Mid Caches
[ https://issues.apache.org/jira/browse/TC-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-320: --- Fix Version/s: 2.2.0 > cache url config parameters not created at the Mid Caches > - > > Key: TC-320 > URL: https://issues.apache.org/jira/browse/TC-320 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Steve Malenfant >Priority: Minor > Labels: cache_url, configuration > Fix For: 2.2.0 > > > From GH issue https://github.com/Comcast/traffic_control/issues/1743: > We created a new delivery service and used the Cache URL expression. The > parameters got created for Edges, but not for the Mids. Thus making ORT and > ATS complain. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-312) Hosts in PRE_PROD status with updates queued will prevent children from updating
[ https://issues.apache.org/jira/browse/TC-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-312: --- Fix Version/s: 2.2.0 > Hosts in PRE_PROD status with updates queued will prevent children from > updating > > > Key: TC-312 > URL: https://issues.apache.org/jira/browse/TC-312 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops ORT >Reporter: Dan Kirkwood >Priority: Minor > Labels: pre_prod, updates > Fix For: 2.2.0 > > > Children of hosts set to PRE_PROD will exit syncds because their parents > still need an update. PRE_PROD should be ignored since they may not have the > capability or the software needed to run syncds. > from https://github.com/Comcast/traffic_control/issues/1517 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-317) ORT syncds bug - Parent holds up child running syncds if TO has multiple CDNs
[ https://issues.apache.org/jira/browse/TC-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-317: --- Fix Version/s: 2.1.0 > ORT syncds bug - Parent holds up child running syncds if TO has multiple CDNs > - > > Key: TC-317 > URL: https://issues.apache.org/jira/browse/TC-317 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops ORT >Reporter: Nir Sopher > Labels: syncds > Fix For: 2.1.0 > > > Based on: https://github.com/Comcast/traffic_control/issues/1380 > By: jpappa200 > A parent from a different CDN can hold up a child from running syncds if > Traffic Ops has multiple CDN's configured. > https:///update/ looks at all parents associated with the cache > group and doesn't check which CDN it's associated with. > Comment by jeffmart: > Is this hold up indefinite? > or > does syncds complete on the child after all parents for all CDNs in that > cache group are updated? > I am assuming https://github.com/Comcast/traffic_control/pull/2 but want to > make sure > knutsel : > so we have a issue somewhere to take regex_revalidate out of the ort/syncds > distribution mechanism, and scp (or ansible dist) it directly on update; this > would remove the "mids have to complete ort syncds before edges" requirement, > and things should get a lot better when we do that... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-308) hdr_rw_* gets inserted in profiles, but they don't get removed...
[
https://issues.apache.org/jira/browse/TC-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-308:
---
Affects Version/s: 1.8.0
> hdr_rw_* gets inserted in profiles, but they don't get removed...
> -
>
> Key: TC-308
> URL: https://issues.apache.org/jira/browse/TC-308
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Ops
>Affects Versions: 1.8.0
>Reporter: Steve Malenfant
>Priority: Minor
> Labels: profile_parameters
>
> Moved from https://github.com/Comcast/traffic_control/issues/714
> Spend lots of time troubleshooting an config file generation issue which
> referred to a delivery service that was deleted or renamed.
> If you look at the Profile Parameters, you'll notice there is entries you
> probably never created yourselves. During configuration file generation,
> looks like it looks for "^hdr_rw_mid" to see if needs to generate a file.
> If the parameter still exists and the delivery service doesn't, it throws an
> error on either line 1210 or 1216 (looks like edge_header_rewrite is causing
> a problem too).
> Removing the parameter does fix the problem. Do we really need to insert
> those "locations" in the database?
> sub header_rewrite_dot_config {
> my $self = shift;
> my $id = shift;
> my $file = shift;
> my $server= $self->server_data($id);
> my $text = $self->header_comment( $server->host_name );
> my $ds_xml_id = undef;
> if ( $file =~ /^hdr_rw_mid_(.*)\.config$/ ) {
> $ds_xml_id = $1;
> my $ds = $self->db->resultset('Deliveryservice')->search( { xml_id =>
> $ds_xml_id }, { prefetch => [ 'type', 'profile' ] } )->single();
> my $actions = $ds->mid_header_rewrite;
> $text .= $actions . "\n";
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-308) hdr_rw_* gets inserted in profiles, but they don't get removed...
[
https://issues.apache.org/jira/browse/TC-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-308:
---
Issue Type: Improvement (was: Bug)
> hdr_rw_* gets inserted in profiles, but they don't get removed...
> -
>
> Key: TC-308
> URL: https://issues.apache.org/jira/browse/TC-308
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Ops
>Affects Versions: 1.8.0
>Reporter: Steve Malenfant
>Priority: Minor
> Labels: profile_parameters
>
> Moved from https://github.com/Comcast/traffic_control/issues/714
> Spend lots of time troubleshooting an config file generation issue which
> referred to a delivery service that was deleted or renamed.
> If you look at the Profile Parameters, you'll notice there is entries you
> probably never created yourselves. During configuration file generation,
> looks like it looks for "^hdr_rw_mid" to see if needs to generate a file.
> If the parameter still exists and the delivery service doesn't, it throws an
> error on either line 1210 or 1216 (looks like edge_header_rewrite is causing
> a problem too).
> Removing the parameter does fix the problem. Do we really need to insert
> those "locations" in the database?
> sub header_rewrite_dot_config {
> my $self = shift;
> my $id = shift;
> my $file = shift;
> my $server= $self->server_data($id);
> my $text = $self->header_comment( $server->host_name );
> my $ds_xml_id = undef;
> if ( $file =~ /^hdr_rw_mid_(.*)\.config$/ ) {
> $ds_xml_id = $1;
> my $ds = $self->db->resultset('Deliveryservice')->search( { xml_id =>
> $ds_xml_id }, { prefetch => [ 'type', 'profile' ] } )->single();
> my $actions = $ds->mid_header_rewrite;
> $text .= $actions . "\n";
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-306) API does not handle anymap revalidation requests properly
[
https://issues.apache.org/jira/browse/TC-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-306:
---
Affects Version/s: 2.2.0
2.1.0
> API does not handle anymap revalidation requests properly
> -
>
> Key: TC-306
> URL: https://issues.apache.org/jira/browse/TC-306
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Derek Gelinas
>Priority: Minor
> Labels: invalidation
> Fix For: 2.2.0
>
>
> (pulled from the github issue tracker of old)
> I issued an API call to invalidate some content for an ANY_MAP delivery
> service:
> [coolguy@randomhost ccdn] curl -o $HOME/foobar.com.stuff_purge.out -b
> /tmp/cookie -c /tmp/cookie --insecure -H 'Accept: application/json' -X POST
> --data '{ "dsId":"441", "regex":"/\d+/foobar.com/stuff1/",
> "startTime":"2016-01-29 18:06:40", "ttl":168 }'
> https://qa-host.kabletown.net/api/1.2/user/current/jobs
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 214 116 116 116 0 98 10 8 0:00:11 0:00:11 --:--:-- 5
> [coolguy@randomhost ccdn] cat $HOME/foobar.com.stuff_purge.out
> {"alerts":[{"level":"success","text":"Successfully created purge job for:
> /\d+/foobar.com/stuff1/(TTL:168h)"}]}[Fri Jan 29][18:07:23]
> [coolguy@randomhost ccdn]
> I then went into the UI and issued a separate invalidation request but
> changed the URI slightly (stuff1 became stuff2).
> If you run a report, you can see the difference:
> [root@midhost coolguy]# /opt/ort/traffic_ops_ort.pl report error
> https://qa-host.kabletown.net admin:
> Fri Jan 29 18:17:41 UTC 2016
> Version of this script: 0.55c
> ERROR Traffic Ops is signaling that an update is waiting to be applied.
> ERROR Lines for /opt/trafficserver/etc/trafficserver/regex_revalidate.config
> from Traffic Ops do not match file on disk.
> ERROR Config file regex_revalidate.config line only in TrOps:
> /\d+/foobar.com/stuff1/ 1454263660
> ERROR Config file regex_revalidate.config line only in TrOps:
> http://slow-([a-z0-9]+)-([0-9]+).sys.kabletown.net/\d+/foobar.com/stuff2
> 1454264281
> [root@midhost coolguy]#
> We're missing the hostname regex on the API call.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-303) Influx summary query returns results not found in the corresponding series query (i.e. max and min)
[
https://issues.apache.org/jira/browse/TC-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-303:
---
Affects Version/s: 2.2.0
> Influx summary query returns results not found in the corresponding series
> query (i.e. max and min)
>
>
> Key: TC-303
> URL: https://issues.apache.org/jira/browse/TC-303
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Dan Kirkwood
>Priority: Minor
> Labels: influx
> Fix For: 2.2.0
>
>
> From https://github.com/Comcast/traffic_control/issues/539
> For example, the influx series query results may look like this:
> [
> [time, value],
> [time, 10],
> [time, 20],
> [time, 34],
> [time, 26]
> ]
> and the influx summary query results for the same timeframe may look like:
> {
> time: x,
> mean: y,
> min: 8,
> max: 75
> }
> notice how the min=8 and max=75 is strange because 8 and 75 are not found in
> the series query. this is because the series query is being grouped into 60s
> intervals (which is an average of 6 10s intervals) but the summary query
> looks at every value recorded in influx (on the 10s interval) between the
> timeframe.
> so in this example, i would expect min=10 and max=34
> maybe it's possible to run the summary query against the series query
> results?? like a subselect query like this:
> SELECT mean(value), percentile(value, 5), percentile(value, 95),
> percentile(value, 98), min(value), max(value), count(value) FROM (SELECT
> sum(value)/count(value) FROM tps_total WHERE cachegroup = 'total' AND
> deliveryservice = 'ds-name' AND time >='2015-09-17T03:38:00-06:00' AND time
> <= '2015-09-17T15:38:00-06:00' GROUP BY time(60s), cachegroup)
> this bug pertains to the following api endpoint
> /api/version/deliveryservice_stats.json when data source is influx.
> here are a couple sample influx queries:
> summary_query #-> $VAR1 = 'SELECT mean(value), percentile(value, 5),
> percentile(value, 95), percentile(value, 98), min(value), max(value),
> count(value) FROM tps_total WHERE time >= '2015-09-17T03:38:00-06:00' AND
> time <= '2015-09-17T15:38:00-06:00' AND cachegroup = 'total' AND
> deliveryservice = 'ds-name'';
> series_query #-> $VAR1 = 'SELECT sum(value)/count(value) FROM tps_total WHERE
> cachegroup = 'total' AND deliveryservice = 'ds-name' AND time
> >='2015-09-17T03:38:00-06:00' AND time <= '2015-09-17T15:38:00-06:00' GROUP
> BY time(60s), cachegroup';
> from [~mitchell...@apache.org]:
> this is not fixed. :( if you pass in another interval like 1h, this issue
> again occurs.
> this will require a summary query based on a series query or basically a
> nested query as the issue suggested and nested queries are not yet supported
> in influxdb - influxdb/influxdb#52
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-303) Influx summary query returns results not found in the corresponding series query (i.e. max and min)
[
https://issues.apache.org/jira/browse/TC-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-303:
---
Fix Version/s: 2.2.0
> Influx summary query returns results not found in the corresponding series
> query (i.e. max and min)
>
>
> Key: TC-303
> URL: https://issues.apache.org/jira/browse/TC-303
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Dan Kirkwood
>Priority: Minor
> Labels: influx
> Fix For: 2.2.0
>
>
> From https://github.com/Comcast/traffic_control/issues/539
> For example, the influx series query results may look like this:
> [
> [time, value],
> [time, 10],
> [time, 20],
> [time, 34],
> [time, 26]
> ]
> and the influx summary query results for the same timeframe may look like:
> {
> time: x,
> mean: y,
> min: 8,
> max: 75
> }
> notice how the min=8 and max=75 is strange because 8 and 75 are not found in
> the series query. this is because the series query is being grouped into 60s
> intervals (which is an average of 6 10s intervals) but the summary query
> looks at every value recorded in influx (on the 10s interval) between the
> timeframe.
> so in this example, i would expect min=10 and max=34
> maybe it's possible to run the summary query against the series query
> results?? like a subselect query like this:
> SELECT mean(value), percentile(value, 5), percentile(value, 95),
> percentile(value, 98), min(value), max(value), count(value) FROM (SELECT
> sum(value)/count(value) FROM tps_total WHERE cachegroup = 'total' AND
> deliveryservice = 'ds-name' AND time >='2015-09-17T03:38:00-06:00' AND time
> <= '2015-09-17T15:38:00-06:00' GROUP BY time(60s), cachegroup)
> this bug pertains to the following api endpoint
> /api/version/deliveryservice_stats.json when data source is influx.
> here are a couple sample influx queries:
> summary_query #-> $VAR1 = 'SELECT mean(value), percentile(value, 5),
> percentile(value, 95), percentile(value, 98), min(value), max(value),
> count(value) FROM tps_total WHERE time >= '2015-09-17T03:38:00-06:00' AND
> time <= '2015-09-17T15:38:00-06:00' AND cachegroup = 'total' AND
> deliveryservice = 'ds-name'';
> series_query #-> $VAR1 = 'SELECT sum(value)/count(value) FROM tps_total WHERE
> cachegroup = 'total' AND deliveryservice = 'ds-name' AND time
> >='2015-09-17T03:38:00-06:00' AND time <= '2015-09-17T15:38:00-06:00' GROUP
> BY time(60s), cachegroup';
> from [~mitchell...@apache.org]:
> this is not fixed. :( if you pass in another interval like 1h, this issue
> again occurs.
> this will require a summary query based on a series query or basically a
> nested query as the issue suggested and nested queries are not yet supported
> in influxdb - influxdb/influxdb#52
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-306) API does not handle anymap revalidation requests properly
[
https://issues.apache.org/jira/browse/TC-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-306:
---
Fix Version/s: 2.2.0
> API does not handle anymap revalidation requests properly
> -
>
> Key: TC-306
> URL: https://issues.apache.org/jira/browse/TC-306
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops, Traffic Ops API
>Reporter: Derek Gelinas
>Priority: Minor
> Labels: invalidation
> Fix For: 2.2.0
>
>
> (pulled from the github issue tracker of old)
> I issued an API call to invalidate some content for an ANY_MAP delivery
> service:
> [coolguy@randomhost ccdn] curl -o $HOME/foobar.com.stuff_purge.out -b
> /tmp/cookie -c /tmp/cookie --insecure -H 'Accept: application/json' -X POST
> --data '{ "dsId":"441", "regex":"/\d+/foobar.com/stuff1/",
> "startTime":"2016-01-29 18:06:40", "ttl":168 }'
> https://qa-host.kabletown.net/api/1.2/user/current/jobs
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 214 116 116 116 0 98 10 8 0:00:11 0:00:11 --:--:-- 5
> [coolguy@randomhost ccdn] cat $HOME/foobar.com.stuff_purge.out
> {"alerts":[{"level":"success","text":"Successfully created purge job for:
> /\d+/foobar.com/stuff1/(TTL:168h)"}]}[Fri Jan 29][18:07:23]
> [coolguy@randomhost ccdn]
> I then went into the UI and issued a separate invalidation request but
> changed the URI slightly (stuff1 became stuff2).
> If you run a report, you can see the difference:
> [root@midhost coolguy]# /opt/ort/traffic_ops_ort.pl report error
> https://qa-host.kabletown.net admin:
> Fri Jan 29 18:17:41 UTC 2016
> Version of this script: 0.55c
> ERROR Traffic Ops is signaling that an update is waiting to be applied.
> ERROR Lines for /opt/trafficserver/etc/trafficserver/regex_revalidate.config
> from Traffic Ops do not match file on disk.
> ERROR Config file regex_revalidate.config line only in TrOps:
> /\d+/foobar.com/stuff1/ 1454263660
> ERROR Config file regex_revalidate.config line only in TrOps:
> http://slow-([a-z0-9]+)-([0-9]+).sys.kabletown.net/\d+/foobar.com/stuff2
> 1454264281
> [root@midhost coolguy]#
> We're missing the hostname regex on the API call.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-302) Change Log Created On Edit Profile Details and Close - GH #1341
[ https://issues.apache.org/jira/browse/TC-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-302: --- Fix Version/s: 2.2.0 > Change Log Created On Edit Profile Details and Close - GH #1341 > --- > > Key: TC-302 > URL: https://issues.apache.org/jira/browse/TC-302 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.2.0 >Reporter: Dewayne Richardson >Priority: Minor > Labels: configuration, logs > Fix For: 2.2.0 > > > The original issue was https://github.com/Comcast/traffic_control/issues/1341 > I was seeing some Change Log entries which made me question my team mates. > Update profile with name: EDGE_R730XD_532-733 > They haven't changed anything, but here's the steps to reproduce. > Parameters -> Select Profile > Select Profile Details > Select Edit > Select Close (So no change are done, they simply wanted to copy) > At this point, a change log entry is produced for something that wasn't > updated. > https://github.com/Comcast/traffic_control/blob/master/traffic_ops/app/lib/UI/Profile.pm#L190-L212 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TC-302) Change Log Created On Edit Profile Details and Close - GH #1341
[ https://issues.apache.org/jira/browse/TC-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16126068#comment-16126068 ] Hank Beatty edited comment on TC-302 at 8/16/17 3:31 PM: - [~smalenfant] Is this still an issue? If so, should it be fixed in 2.1? was (Author: hbeatty): [~smalenfant] Is this still an issue? If so, should it be fixed in 2.1? Link to original github issue: https://github.com/Comcast/traffic_control/issues/896 > Change Log Created On Edit Profile Details and Close - GH #1341 > --- > > Key: TC-302 > URL: https://issues.apache.org/jira/browse/TC-302 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.2.0 >Reporter: Dewayne Richardson >Priority: Minor > Labels: configuration, logs > > I was seeing some Change Log entries which made me question my team mates. > Update profile with name: EDGE_R730XD_532-733 > They haven't changed anything, but here's the steps to reproduce. > Parameters -> Select Profile > Select Profile Details > Select Edit > Select Close (So no change are done, they simply wanted to copy) > At this point, a change log entry is produced for something that wasn't > updated. > https://github.com/Comcast/traffic_control/blob/master/traffic_ops/app/lib/UI/Profile.pm#L190-L212 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-302) Change Log Created On Edit Profile Details and Close - GH #1341
[ https://issues.apache.org/jira/browse/TC-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-302: --- Description: The original issue was https://github.com/Comcast/traffic_control/issues/1341 I was seeing some Change Log entries which made me question my team mates. Update profile with name: EDGE_R730XD_532-733 They haven't changed anything, but here's the steps to reproduce. Parameters -> Select Profile Select Profile Details Select Edit Select Close (So no change are done, they simply wanted to copy) At this point, a change log entry is produced for something that wasn't updated. https://github.com/Comcast/traffic_control/blob/master/traffic_ops/app/lib/UI/Profile.pm#L190-L212 was: I was seeing some Change Log entries which made me question my team mates. Update profile with name: EDGE_R730XD_532-733 They haven't changed anything, but here's the steps to reproduce. Parameters -> Select Profile Select Profile Details Select Edit Select Close (So no change are done, they simply wanted to copy) At this point, a change log entry is produced for something that wasn't updated. https://github.com/Comcast/traffic_control/blob/master/traffic_ops/app/lib/UI/Profile.pm#L190-L212 > Change Log Created On Edit Profile Details and Close - GH #1341 > --- > > Key: TC-302 > URL: https://issues.apache.org/jira/browse/TC-302 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.2.0 >Reporter: Dewayne Richardson >Priority: Minor > Labels: configuration, logs > > The original issue was https://github.com/Comcast/traffic_control/issues/1341 > I was seeing some Change Log entries which made me question my team mates. > Update profile with name: EDGE_R730XD_532-733 > They haven't changed anything, but here's the steps to reproduce. > Parameters -> Select Profile > Select Profile Details > Select Edit > Select Close (So no change are done, they simply wanted to copy) > At this point, a change log entry is produced for something that wasn't > updated. > https://github.com/Comcast/traffic_control/blob/master/traffic_ops/app/lib/UI/Profile.pm#L190-L212 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-301) creating https delivery service and not setting to active still looks for cert. Github Issue #1086
[ https://issues.apache.org/jira/browse/TC-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-301: --- Fix Version/s: 2.1.0 > creating https delivery service and not setting to active still looks for > cert. Github Issue #1086 > -- > > Key: TC-301 > URL: https://issues.apache.org/jira/browse/TC-301 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Dewayne Richardson > Labels: Configuration, SSL > Fix For: 2.1.0 > > > Original GH issue https://github.com/Comcast/traffic_control/issues/1086 > Que'ed and snapshotted - delivery service was not set to active. On syncds it > err's looking for DS cert. > ERROR Received error code 400 for > https://trafficops/api/1.1/deliveryservices/hostname/deliveryservicename/sslkeys.json > from Traffic Ops! > FATAL SSL URL: > https://trafficops/api/1.1/deliveryservices/hostname/deliveryservicename/sslkeys.json > returned 400. Exiting. > Just generating a ssl key and error goes away. > Copying /tmp/ort/123/trafficserver/config_trops deliveryservicename .cer to > /opt/trafficserver/etc/trafficserver/ssl//deliveryservicename_cert.cer > ERROR Copying /tmp/ort/123/trafficserver/config_trops/deliveryservicename.key > to /opt/trafficserver/etc/trafficserver/ssl//deliveryservicename.key -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-301) creating https delivery service and not setting to active still looks for cert. Github Issue #1086
[ https://issues.apache.org/jira/browse/TC-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-301: --- Description: Original GH issue https://github.com/Comcast/traffic_control/issues/1086 Que'ed and snapshotted - delivery service was not set to active. On syncds it err's looking for DS cert. ERROR Received error code 400 for https://trafficops/api/1.1/deliveryservices/hostname/deliveryservicename/sslkeys.json from Traffic Ops! FATAL SSL URL: https://trafficops/api/1.1/deliveryservices/hostname/deliveryservicename/sslkeys.json returned 400. Exiting. Just generating a ssl key and error goes away. Copying /tmp/ort/123/trafficserver/config_trops deliveryservicename .cer to /opt/trafficserver/etc/trafficserver/ssl//deliveryservicename_cert.cer ERROR Copying /tmp/ort/123/trafficserver/config_trops/deliveryservicename.key to /opt/trafficserver/etc/trafficserver/ssl//deliveryservicename.key was: Que'ed and snapshotted - delivery service was not set to active. On syncds it err's looking for DS cert. ERROR Received error code 400 for https://trafficops/api/1.1/deliveryservices/hostname/deliveryservicename/sslkeys.json from Traffic Ops! FATAL SSL URL: https://trafficops/api/1.1/deliveryservices/hostname/deliveryservicename/sslkeys.json returned 400. Exiting. Just generating a ssl key and error goes away. Copying /tmp/ort/123/trafficserver/config_trops deliveryservicename .cer to /opt/trafficserver/etc/trafficserver/ssl//deliveryservicename_cert.cer ERROR Copying /tmp/ort/123/trafficserver/config_trops/deliveryservicename.key to /opt/trafficserver/etc/trafficserver/ssl//deliveryservicename.key > creating https delivery service and not setting to active still looks for > cert. Github Issue #1086 > -- > > Key: TC-301 > URL: https://issues.apache.org/jira/browse/TC-301 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Dewayne Richardson > Labels: Configuration, SSL > > Original GH issue https://github.com/Comcast/traffic_control/issues/1086 > Que'ed and snapshotted - delivery service was not set to active. On syncds it > err's looking for DS cert. > ERROR Received error code 400 for > https://trafficops/api/1.1/deliveryservices/hostname/deliveryservicename/sslkeys.json > from Traffic Ops! > FATAL SSL URL: > https://trafficops/api/1.1/deliveryservices/hostname/deliveryservicename/sslkeys.json > returned 400. Exiting. > Just generating a ssl key and error goes away. > Copying /tmp/ort/123/trafficserver/config_trops deliveryservicename .cer to > /opt/trafficserver/etc/trafficserver/ssl//deliveryservicename_cert.cer > ERROR Copying /tmp/ort/123/trafficserver/config_trops/deliveryservicename.key > to /opt/trafficserver/etc/trafficserver/ssl//deliveryservicename.key -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-298) Health params.json updated with certain Profile names Github Issue #896
[ https://issues.apache.org/jira/browse/TC-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-298: --- Issue Type: Improvement (was: Bug) > Health params.json updated with certain Profile names Github Issue #896 > --- > > Key: TC-298 > URL: https://issues.apache.org/jira/browse/TC-298 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Dewayne Richardson > Labels: heath_params.json, profile > Fix For: 2.1.0, 2.2.0 > > > Create Profile names in the Traffic_OPs with names such as Edge and Mid for > Edge and Mid cache profiles, these don't get updated in the heath_params.json > on the Traffic monitor. > In the current implementation of traffic ops, there is no "type" for a > profile. When generating the health-params.json for traffic monitor, ops do > not know which profile is for edge or middle or router, etc. So in traffic > ops code, it use the convention that: > profile starting with "RASCAL" is a traffic monitor profile > profile starting with "CCR" is a traffic router profile > profile starting with "EDGE" is an edge server profile > profile starting with "MID" is a middle server profile > It is better to add a type for each profile, or make a restriction for the > profile name. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-298) Health params.json updated with certain Profile names Github Issue #896
[ https://issues.apache.org/jira/browse/TC-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-298: --- Affects Version/s: 2.2.0 2.1.0 > Health params.json updated with certain Profile names Github Issue #896 > --- > > Key: TC-298 > URL: https://issues.apache.org/jira/browse/TC-298 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Dewayne Richardson > Labels: heath_params.json, profile > Fix For: 2.1.0, 2.2.0 > > > Create Profile names in the Traffic_OPs with names such as Edge and Mid for > Edge and Mid cache profiles, these don't get updated in the heath_params.json > on the Traffic monitor. > In the current implementation of traffic ops, there is no "type" for a > profile. When generating the health-params.json for traffic monitor, ops do > not know which profile is for edge or middle or router, etc. So in traffic > ops code, it use the convention that: > profile starting with "RASCAL" is a traffic monitor profile > profile starting with "CCR" is a traffic router profile > profile starting with "EDGE" is an edge server profile > profile starting with "MID" is a middle server profile > It is better to add a type for each profile, or make a restriction for the > profile name. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-298) Health params.json updated with certain Profile names Github Issue #896
[ https://issues.apache.org/jira/browse/TC-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-298: --- Fix Version/s: 2.2.0 2.1.0 > Health params.json updated with certain Profile names Github Issue #896 > --- > > Key: TC-298 > URL: https://issues.apache.org/jira/browse/TC-298 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Dewayne Richardson > Labels: heath_params.json, profile > Fix For: 2.1.0, 2.2.0 > > > Create Profile names in the Traffic_OPs with names such as Edge and Mid for > Edge and Mid cache profiles, these don't get updated in the heath_params.json > on the Traffic monitor. > In the current implementation of traffic ops, there is no "type" for a > profile. When generating the health-params.json for traffic monitor, ops do > not know which profile is for edge or middle or router, etc. So in traffic > ops code, it use the convention that: > profile starting with "RASCAL" is a traffic monitor profile > profile starting with "CCR" is a traffic router profile > profile starting with "EDGE" is an edge server profile > profile starting with "MID" is a middle server profile > It is better to add a type for each profile, or make a restriction for the > profile name. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-296) ANY_MAP doesn't get applied to the mids
[ https://issues.apache.org/jira/browse/TC-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-296: --- Fix Version/s: 2.2.0 > ANY_MAP doesn't get applied to the mids > --- > > Key: TC-296 > URL: https://issues.apache.org/jira/browse/TC-296 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Eric Friedrich >Priority: Minor > Labels: any_map, remap.conf > Fix For: 2.2.0 > > > Delivery services of type ANY_MAP only gets a line in remap.conf for caches > of type EDGE. > https://github.com/Comcast/traffic_control/issues/740 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-297) Handle domain name for ntp servers in ORT Check
[ https://issues.apache.org/jira/browse/TC-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-297: --- Fix Version/s: 2.2.0 > Handle domain name for ntp servers in ORT Check > --- > > Key: TC-297 > URL: https://issues.apache.org/jira/browse/TC-297 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops ORT >Affects Versions: 2.1.0, 2.2.0 >Reporter: Steve Malenfant >Priority: Minor > Labels: ntp, ntp.conf > Fix For: 2.2.0 > > > From GH issue #566: > check_ntp doesn't handle domain name in the ntp.conf. It also doesn't handle > pool of servers. Seems to only handle an IP address. > Not sure if that's actually possible. Would a check if "NTP" is sync'd be > enough? > Does it cause a problem? No. > Does it report an error? Yes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-297) Handle domain name for ntp servers in ORT Check
[ https://issues.apache.org/jira/browse/TC-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-297: --- Affects Version/s: 2.2.0 2.1.0 > Handle domain name for ntp servers in ORT Check > --- > > Key: TC-297 > URL: https://issues.apache.org/jira/browse/TC-297 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops ORT >Affects Versions: 2.1.0, 2.2.0 >Reporter: Steve Malenfant >Priority: Minor > Labels: ntp, ntp.conf > Fix For: 2.2.0 > > > From GH issue #566: > check_ntp doesn't handle domain name in the ntp.conf. It also doesn't handle > pool of servers. Seems to only handle an IP address. > Not sure if that's actually possible. Would a check if "NTP" is sync'd be > enough? > Does it cause a problem? No. > Does it report an error? Yes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-296) ANY_MAP doesn't get applied to the mids
[ https://issues.apache.org/jira/browse/TC-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-296: --- Affects Version/s: 2.2.0 > ANY_MAP doesn't get applied to the mids > --- > > Key: TC-296 > URL: https://issues.apache.org/jira/browse/TC-296 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Eric Friedrich >Priority: Minor > Labels: any_map, remap.conf > > Delivery services of type ANY_MAP only gets a line in remap.conf for caches > of type EDGE. > https://github.com/Comcast/traffic_control/issues/740 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-294) Missing location parameter leads to broken remap.config
[ https://issues.apache.org/jira/browse/TC-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-294: --- Affects Version/s: 2.2.0 2.1.0 > Missing location parameter leads to broken remap.config > --- > > Key: TC-294 > URL: https://issues.apache.org/jira/browse/TC-294 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops ORT >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Mark Torluemke >Priority: Minor > Labels: remap.config > Fix For: 2.2.0 > > > From the original GH issue #195: > For things like header_rewrite, cacheurl, etc, there isn't value in managing > the 'location' parameter outside the delivery service assignment to the > caches...is there? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-295) Invalid DS regex causes nasty exception and unexpected results Github Issue #514
[ https://issues.apache.org/jira/browse/TC-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-295: --- Fix Version/s: (was: 2.0.0) 2.2.0 > Invalid DS regex causes nasty exception and unexpected results Github Issue > #514 > > > Key: TC-295 > URL: https://issues.apache.org/jira/browse/TC-295 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Dewayne Richardson > Labels: configuration, regex > Fix For: 2.2.0 > > > If a host regex (probably others) is specified as a plain string, rather than > a real regex (e.g.: test vs ..mydeliveryservice..), the following exception > occurs in Traffic Router, and the user would have to be watching the logs to > see that something went wrong. Additionally, it is not clear why the failure > occurred. > Improve TO in general such that the regex is clearly defined (documented?) > and potentially checked so that it doesn't get added to the CRConfig until it > is what we expect to see. Additionally, discuss whether we want to support > specific strings (e.g.: test) instead of a full regex. Doing so seems to be > counter to the intent of the regex in the first place, so I do not think that > this is a viable option at this time. > WARN 2015-09-01T14:25:07.237 [New I/O worker #1] > com.comcast.cdn.traffic_control.traffic_router.core.util.PeriodicResourceUpdater > - 1 java.lang.ArrayIndexOutOfBoundsException: 1 at > com.comcast.cdn.traffic_control.traffic_router.core.dns.ZoneManager.populateZoneMap(ZoneManager.java:311) > at > com.comcast.cdn.traffic_control.traffic_router.core.dns.ZoneManager.generateZones(ZoneManager.java:132) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-294) Missing location parameter leads to broken remap.config
[ https://issues.apache.org/jira/browse/TC-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-294: --- Fix Version/s: 2.2.0 > Missing location parameter leads to broken remap.config > --- > > Key: TC-294 > URL: https://issues.apache.org/jira/browse/TC-294 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops ORT >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Mark Torluemke >Priority: Minor > Labels: remap.config > Fix For: 2.2.0 > > > From the original GH issue #195: > For things like header_rewrite, cacheurl, etc, there isn't value in managing > the 'location' parameter outside the delivery service assignment to the > caches...is there? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-291) GenIso can't handle concurrent requests
[
https://issues.apache.org/jira/browse/TC-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-291:
---
Fix Version/s: 2.2.0
2.1.0
> GenIso can't handle concurrent requests
>
>
> Key: TC-291
> URL: https://issues.apache.org/jira/browse/TC-291
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0, 2.0.0, 2.2.0
>Reporter: Dewayne Richardson
> Labels: genlso
> Fix For: 2.1.0, 2.2.0
>
>
> Because GenIso always changes the same files (no temporary directories
> created), it can't handle concurrent requests. We sometimes send commands to
> create 10 Edge Caches at the same time and we found out that the wrong IP
> address shows up on servers.
> I've got the code to fix it up (but need to sign our paperwork). But our
> GenIso.pm now deviates from what's in Traffic Ops because we wanted to keep
> the 1.0.0 functionality (don't use the install_cfg directory, keep using the
> simple network line).
> Suggestion: We should have a parameter to call different ISO generator
> scripts. Seems like this is implementation specific and not really a core
> function of Traffic Ops.
> Basic changes :
> use File::Temp;
> use File::Copy::Recursive;
> my $tmpdir = File::Temp::tempdir(CLEANUP => 1);
> ...
> GenIso.pm:my $tmp = File::Copy::Recursive::dircopy($dir,$tmpdir);
> GenIso.pm: my $cfg_dir = "$tmpdir/$install_cfg";
> GenIso.pm: print STUF "Dir== $tmpdir\n";
> GenIso.pm: my $cmd = "mkisofs -joliet-long -input-charset utf-8 -b
> isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4
> -boot-info-table -R -J -v -T $tmpdir";
> GenIso.pm: open(IN, "<$tmpdir/ks.src") || die("$tmpdir/ks.src:$!");
> GenIso.pm: open (OUT, ">$tmpdir/ks.cfg") || die("$tmpdir/ks.cfg:$!");
> GenIso.pm:File::Path::rmtree $tmpdir;
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-277) Riak server setting offline fails with error
[ https://issues.apache.org/jira/browse/TC-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-277: --- Affects Version/s: 2.2.0 > Riak server setting offline fails with error > > > Key: TC-277 > URL: https://issues.apache.org/jira/browse/TC-277 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops Client >Affects Versions: 2.1.0, 2.2.0 > Environment: Chrome on Mac OS X >Reporter: Joseph Pappano >Priority: Minor > Labels: riak > Fix For: 2.2.0 > > Attachments: Screen Shot 2017-05-08 at 3.23.42 PM.png > > > Setting Riak server offline by clicking edit -> edit -> changing status to > offline and adding comment -> submit will result in an error. > clicking edit -> offline server button will succeed. > attached screenshot of error. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-277) Riak server setting offline fails with error
[ https://issues.apache.org/jira/browse/TC-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-277: --- Fix Version/s: 2.2.0 > Riak server setting offline fails with error > > > Key: TC-277 > URL: https://issues.apache.org/jira/browse/TC-277 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops Client >Affects Versions: 2.1.0, 2.2.0 > Environment: Chrome on Mac OS X >Reporter: Joseph Pappano >Priority: Minor > Labels: riak > Fix For: 2.2.0 > > Attachments: Screen Shot 2017-05-08 at 3.23.42 PM.png > > > Setting Riak server offline by clicking edit -> edit -> changing status to > offline and adding comment -> submit will result in an error. > clicking edit -> offline server button will succeed. > attached screenshot of error. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-210) User agent and application versions incorrect
[
https://issues.apache.org/jira/browse/TC-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-210:
---
Affects Version/s: 2.2.0
2.1.0
> User agent and application versions incorrect
> -
>
> Key: TC-210
> URL: https://issues.apache.org/jira/browse/TC-210
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Monitor (golang)
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jeff Elsloo
>Assignee: Robert Butts
>Priority: Minor
> Labels: user_agent
> Fix For: 2.2.0
>
>
> The experimental (golang) Traffic Monitors appear to have a hardcoded version
> in the user agent string. This shouldn't really be hardcoded, or if it is,
> should be search/replaced at compile-time.
> {{common/fetcher/fetcher.go: req.Header.Set("User-Agent",
> "traffic_monitor/1.0") // TODO change to 2.0?}}
> Additionally, the version served up by the application does not match the RPM
> version.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-210) User agent and application versions incorrect
[
https://issues.apache.org/jira/browse/TC-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-210:
---
Fix Version/s: 2.2.0
> User agent and application versions incorrect
> -
>
> Key: TC-210
> URL: https://issues.apache.org/jira/browse/TC-210
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Monitor (golang)
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Jeff Elsloo
>Assignee: Robert Butts
>Priority: Minor
> Labels: user_agent
> Fix For: 2.2.0
>
>
> The experimental (golang) Traffic Monitors appear to have a hardcoded version
> in the user agent string. This shouldn't really be hardcoded, or if it is,
> should be search/replaced at compile-time.
> {{common/fetcher/fetcher.go: req.Header.Set("User-Agent",
> "traffic_monitor/1.0") // TODO change to 2.0?}}
> Additionally, the version served up by the application does not match the RPM
> version.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-209) Experimental Traffic Monitor polling OFFLINE caches
[
https://issues.apache.org/jira/browse/TC-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-209:
---
Fix Version/s: 2.2.0
> Experimental Traffic Monitor polling OFFLINE caches
> ---
>
> Key: TC-209
> URL: https://issues.apache.org/jira/browse/TC-209
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Monitor (golang)
>Affects Versions: 2.1.0, 2.0.0, 2.2.0
>Reporter: Jeff Elsloo
>Assignee: Robert Butts
>Priority: Minor
> Labels: health_monitoring, polling
> Fix For: 2.2.0
>
>
> The experimental (golang) version of Traffic Monitor appears to be polling
> {{OFFLINE}} caches.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-209) Experimental Traffic Monitor polling OFFLINE caches
[
https://issues.apache.org/jira/browse/TC-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hank Beatty updated TC-209:
---
Affects Version/s: 2.2.0
2.1.0
> Experimental Traffic Monitor polling OFFLINE caches
> ---
>
> Key: TC-209
> URL: https://issues.apache.org/jira/browse/TC-209
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Monitor (golang)
>Affects Versions: 2.1.0, 2.0.0, 2.2.0
>Reporter: Jeff Elsloo
>Assignee: Robert Butts
>Priority: Minor
> Labels: health_monitoring, polling
> Fix For: 2.2.0
>
>
> The experimental (golang) version of Traffic Monitor appears to be polling
> {{OFFLINE}} caches.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-169) TR download the RGB file continuously when the same RGB file on server
[ https://issues.apache.org/jira/browse/TC-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-169: --- Fix Version/s: 2.2.0 > 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: 2.1.0, 1.7.0, 2.2.0 >Reporter: Zhilin Huang >Assignee: Zhilin Huang > Labels: rgb > Fix For: 2.1.0, 2.2.0 > > > 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] [Updated] (TC-169) TR download the RGB file continuously when the same RGB file on server
[ https://issues.apache.org/jira/browse/TC-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-169: --- Affects Version/s: 2.2.0 2.1.0 > 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: 2.1.0, 1.7.0, 2.2.0 >Reporter: Zhilin Huang >Assignee: Zhilin Huang > Labels: rgb > Fix For: 2.1.0, 2.2.0 > > > 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] [Updated] (TC-157) Failed to restart tomcat in Traffic Router when failed to get SSL keys
[ https://issues.apache.org/jira/browse/TC-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-157: --- Affects Version/s: 2.2.0 2.1.0 > Failed to restart tomcat in Traffic Router when failed to get SSL keys > -- > > Key: TC-157 > URL: https://issues.apache.org/jira/browse/TC-157 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Router >Affects Versions: 2.1.0, 1.7.0, 2.2.0 >Reporter: Zhilin Huang >Assignee: Zhilin Huang > Labels: ssl, tomcat > Fix For: 2.1.0, 2.2.0 > > Attachments: text.html > > > Stopping tomcat failed with the following log: > WARN 2017-02-17T09:00:05.939 [main] > com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesPublisher > - Detected destroy setting running to false > INFO 2017-02-17T09:00:05.943 [pool-2-thread-1] > com.comcast.cdn.traffic_control.traffic_router.core.secure.CertificatesClient > - Interrupted while pausing for check of traffic ops config > INFO 2017-02-17T09:00:05.943 [pool-2-thread-1] > com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - POSTing: > https://192.168.122.181/api/1.1/user/login; timeout is 15000 > INFO 2017-02-17T09:00:06.005 [pool-2-thread-1] > com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - GETing: > https://192.168.122.181/api/1.2/cdns/name/kabletown_cdn/sslkeys.jso > n; timeout is 15000 > WARN 2017-02-17T09:00:06.040 [pool-2-thread-1] > com.comcast.cdn.traffic_control.traffic_router.core.util.Fetcher - Failed > Http Request to https://192.168.122.181/api/1.2/cdns/name/kabletown_ > cdn/sslkeys.json Status 400 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-161) ort does not restart ATS when it should
[ https://issues.apache.org/jira/browse/TC-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hank Beatty updated TC-161: --- Fix Version/s: 2.2.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, 2.2.0 >Reporter: John Shen >Assignee: John Shen > Fix For: 2.1.0, 2.2.0 > > > ort does not restart ATS when ATS is already running -- This message was sent by Atlassian JIRA (v6.4.14#64029)
