[jira] [Commented] (TC-546) error_url required in the url_sig file
[
https://issues.apache.org/jira/browse/TC-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135933#comment-16135933
]
Steve Malenfant commented on TC-546:
Trafficserver diags.log :
{code:java}
[Aug 21 21:51:26.160] Server {0x2b624f6b9dc0} ERROR: [ReverseProxy] failed to
add remap rule at /opt/trafficserver/etc/trafficserver/remap.config line 30:
Failed to create instance for plugin
"/opt/trafficserver/libexec/trafficserver/url_sig.so": [TSRemapNewInstance] -
Error opening file
/opt/trafficserver/etc/trafficserver//opt/trafficserver/etc/trafficserver/url_sig_example.config.
[Aug 21 21:51:26.160] Server {0x2b624f6b9dc0} WARNING: something failed during
BuildTable() -- check your remap plugins!
[Aug 21 21:51:26.160] Server {0x2b624f6b9dc0} WARNING: Can not load the remap
table, exiting out!
[Aug 21 21:51:44.488] {0x2b8f5afe1dc0} STATUS: opened
/opt/trafficserver/var/log/trafficserver/diags.log
[Aug 21 21:51:44.488] {0x2b8f5afe1dc0} NOTE: updated diags config
{code}
> error_url required in the url_sig file
> --
>
> Key: TC-546
> URL: https://issues.apache.org/jira/browse/TC-546
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0, 2.2.0
> Environment: Traffic Ops 2.1
>Reporter: Steve Malenfant
>
> The error_url parameter in the URL signature file is required, if not present
> trafficserver doesn't start.
> Seems like TO handles generating the proper location of for the url_sig in
> the the database to all servers assigned, although the error_url is not.
> - I tried to put the parameter in the DS profile parameter, but it didn't get
> generated on disk.
> - Thinking that a default of `error_url = 403` should be dynamic generated if
> not present to prevent trafficserver from starting. This could have other
> implication.
> - Other suggestions?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-546) error_url required in the url_sig file
Steve Malenfant created TC-546: -- Summary: error_url required in the url_sig file Key: TC-546 URL: https://issues.apache.org/jira/browse/TC-546 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Affects Versions: 2.1.0, 2.2.0 Environment: Traffic Ops 2.1 Reporter: Steve Malenfant The error_url parameter in the URL signature file is required, if not present trafficserver doesn't start. Seems like TO handles generating the proper location of for the url_sig in the the database to all servers assigned, although the error_url is not. - I tried to put the parameter in the DS profile parameter, but it didn't get generated on disk. - Thinking that a default of `error_url = 403` should be dynamic generated if not present to prevent trafficserver from starting. This could have other implication. - Other suggestions? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-518) ToCDUCheck and ToCHRCheck: Value formatted as float instead of int
[ https://issues.apache.org/jira/browse/TC-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Malenfant reassigned TC-518: -- Assignee: Steve Malenfant > ToCDUCheck and ToCHRCheck: Value formatted as float instead of int > -- > > Key: TC-518 > URL: https://issues.apache.org/jira/browse/TC-518 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Steve Malenfant >Assignee: Steve Malenfant >Priority: Trivial > Fix For: 2.1.0, 2.2.0 > > > CDU check return value are formatted as a float while the database values > were stored as int (mysql) and bigint (postgresql). > This check fails against 2.0+ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (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 ] Steve Malenfant resolved TC-521. Resolution: Fixed > 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] [Assigned] (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
]
Steve Malenfant reassigned TC-514:
--
Assignee: Steve Malenfant (was: Derek Gelinas)
> 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.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] [Created] (TC-534) Traffic Router statistics are not aggregated
Steve Malenfant created TC-534: -- Summary: Traffic Router statistics are not aggregated Key: TC-534 URL: https://issues.apache.org/jira/browse/TC-534 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Affects Versions: 2.1.0, 2.2.0 Reporter: Steve Malenfant Looks like some of the stats APIs related to Traffic Router don't return proper data when there is more than 1 instance of Traffic Router (or will return data for OFFLINE TR). This would affect statistics for Traffic Portal as an example. Looking at the code, it doesn't seem to cycle through all the request routers available to get statistics from a Delivery Service as an example. Known affected APIs : /api/1.2/deliveryservices/:id/routing.json Few things to take in consideration - Skip OFFLINE traffic routers - Skip unreachable traffic routers - Need to aggregate data? Numbers from `/api/1.2/deliveryservices/:id/routing.json` seems to be percentages. Does it matter to get an average from all request routers? Note: I don't have full knowledge of what was intended by this API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-333) Mid Header Rewrite needs to be added to remap.config
[ https://issues.apache.org/jira/browse/TC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127367#comment-16127367 ] Steve Malenfant commented on TC-333: While testing, I could not recreate that condition. Seems like hdr_mid* are now handled properly when : - Assign DS to new cachegroups/profile types - Remove DS from servers/cachegroups - Delete delivery service Closing this issue. > Mid Header Rewrite needs to be added to remap.config > > > Key: TC-333 > URL: https://issues.apache.org/jira/browse/TC-333 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Steve Malenfant >Assignee: Jan van Doorn >Priority: Minor > Labels: header_rewrite > Fix For: 2.1.0 > > > Due to a mis-behaving origin, I want to override the Cache-Control (there > isn't any in my case) using "Mid Header Rewrite". The delivery service > feature does write the proper file to disk, but there is no remap rule set > (basically doesn't do anything). > The following map needs to be added when used: > map http://originfqdn http://originfqdn @plugin=header_rewrite.so > @pparam=hdr_rw_mid_.config > Note: Missing header rewrite in the profile table is the root cause. Need to > make sure they are added. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-333) Mid Header Rewrite needs to be added to remap.config
[ https://issues.apache.org/jira/browse/TC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Malenfant closed TC-333. -- Resolution: Fixed Assignee: Steve Malenfant (was: Jan van Doorn) Fix Version/s: 2.1.0 > Mid Header Rewrite needs to be added to remap.config > > > Key: TC-333 > URL: https://issues.apache.org/jira/browse/TC-333 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Steve Malenfant >Assignee: Steve Malenfant >Priority: Minor > Labels: header_rewrite > Fix For: 2.1.0 > > > Due to a mis-behaving origin, I want to override the Cache-Control (there > isn't any in my case) using "Mid Header Rewrite". The delivery service > feature does write the proper file to disk, but there is no remap rule set > (basically doesn't do anything). > The following map needs to be added when used: > map http://originfqdn http://originfqdn @plugin=header_rewrite.so > @pparam=hdr_rw_mid_.config > Note: Missing header rewrite in the profile table is the root cause. Need to > make sure they are added. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-333) Mid Header Rewrite needs to be added to remap.config
[ https://issues.apache.org/jira/browse/TC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127272#comment-16127272 ] Steve Malenfant commented on TC-333: Looks like header rewrite on mid cache might be broken in 2.1, it writes the ORT debug message instead of the file (and some edge remaps as well). This might be a totally different bug. Need more investigation. I'll send some details to [~dg4prez] > Mid Header Rewrite needs to be added to remap.config > > > Key: TC-333 > URL: https://issues.apache.org/jira/browse/TC-333 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Steve Malenfant >Assignee: Jan van Doorn >Priority: Minor > Labels: header_rewrite > > Due to a mis-behaving origin, I want to override the Cache-Control (there > isn't any in my case) using "Mid Header Rewrite". The delivery service > feature does write the proper file to disk, but there is no remap rule set > (basically doesn't do anything). > The following map needs to be added when used: > map http://originfqdn http://originfqdn @plugin=header_rewrite.so > @pparam=hdr_rw_mid_.config > Note: Missing header rewrite in the profile table is the root cause. Need to > make sure they are added. -- 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
]
Steve Malenfant updated TC-353:
---
Summary: Can't use CNAME hostname with "ccr" prefix (was: Can't CNAME
hostname with "ccr")
> 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
>
> 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] [Commented] (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:comment-tabpanel=16126277#comment-16126277 ] Steve Malenfant commented on TC-368: I believe that is severe enough for Portal users during a TR outage or maintenance. > api/1.2/deliveryservices/:id/routing.json hangs when Traffic Router is > unreachable > -- > > Key: TC-368 > URL: https://issues.apache.org/jira/browse/TC-368 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 1.8.0 >Reporter: Steve Malenfant > Labels: api_deliveryservices, routing > > I was testing this API "/api/1.2/deliveryservices/:id/routing.json" and found > that it would hang and the perl worker had to be killled. This caused 500 > Errors back from TO API. > The root cause is Traffic Router not responding to API Port. > We should not poll Traffic Router that are status=OFFLINE and there should be > some sort of timeouts in place to make sure it doesn't take more than x > seconds to return information from API > There is some comments in the code that seems to indication prior issues. > `# TODO: what happens when the request to CCR times out?` -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-353) Can't CNAME hostname with "ccr"
[
https://issues.apache.org/jira/browse/TC-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16126276#comment-16126276
]
Steve Malenfant commented on TC-353:
I'll submit a PR and let's see if we want to fix in 2.1 as well. Easy fix.
> Can't CNAME hostname with "ccr"
> ---
>
> 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
>
> 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-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
]
Steve Malenfant updated TC-514:
---
Description:
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: ...
> 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
> Environment: Traffic Ops 2.1 and ORT 2.1
>Reporter: Steve Malenfant
>Assignee: Derek Gelinas
>Priority: Minor
>
> 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] [Assigned] (TC-313) Inconsistent edge parent.config configuration using secondary parent
[
https://issues.apache.org/jira/browse/TC-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Malenfant reassigned TC-313:
--
Assignee: Steve Malenfant
> Inconsistent edge parent.config configuration using secondary parent
>
>
> Key: TC-313
> URL: https://issues.apache.org/jira/browse/TC-313
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.0.0, 1.8.0
>Reporter: Matt Mills
>Assignee: Steve Malenfant
>Priority: Minor
> Labels: parent.config
>
> Original issue: https://github.com/Comcast/traffic_control/issues/1349
> I have the following configuration in Traffic Ops :
> | cache-group | primary parent | secondary parent |
> | --- | --- | --- |
> | vm-cdn1-east-edge | vm-cdn1-east-mid | vm-cdn1-west-mid |
> | vm-cdn1-west-edge | vm-cdn1-west-mid | vm-cdn1-east-mid |
> Edge configuration is inconsistent from both a parent/secondary perspective
> and IP/names.
> - `dest_domain=origin.services.coxlab.net` has the proper parents and using
> IPs.
> - `dest_domain=.` has all the parent in the same exact group. Also, it is
> using DNS names instead of IPs. This seems to be there since the beginning.
> - I feel like I'm missing a parameter, but this configuration here doesn't
> look consistent.
> {code}
> dest_domain=origin.services.coxlab.net
> parent="68.1.14.137:80|0.999;68.1.14.138:80|0.999;68.1.14.152:80|0.999;"
> secondary_parent="68.1.14.153:80|0.999;68.1.14.154:80|0.999;68.1.14.155:80|0.999;"
> round_robin=consistent_hash go_direct=false qstring=ignore
> dest_domain=.
> parent="cdn1cdmid0001.coxlab.net:80|0.999;cdn1cdmid0002.coxlab.net:80|0.999;cdn1cdmid0003.coxlab.net:80|0.999;cdn1cdmid0004.coxlab.net:80|0.999;cdn1cdmid0005.coxlab.net:80|0.999;cdn1cdmid0006.coxlab.net:80|0.999;"
> round_robin=consistent_hash go_direct=false qstring=ignore
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (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:comment-tabpanel=16126122#comment-16126122
]
Steve Malenfant commented on TC-308:
[~hbeatty] I need to verify the work that was done in 2.1 regarding DS profiles
and see how this is now handled (if it changed).
Any information related to 2.0 -> 2.1 delivery service change would be great to
have. Would probably be good materials for release notes.
> 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: Bug
> Components: Traffic Ops
>Reporter: Jeremy Mitchell
>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] [Commented] (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=16126089#comment-16126089 ] Steve Malenfant commented on TC-302: [~hbeatty] Tested against 2.1 and the issue is still present. It's actually a little worst since if you click "close" it will save the changes as well. You would expect "save" to save the profile and not "close". Changed Minor. Note: The original issue was https://github.com/Comcast/traffic_control/issues/1341 > 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 >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-518) ToCDUCheck and ToCHRCheck: Value formatted as float instead of int
[ https://issues.apache.org/jira/browse/TC-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Malenfant updated TC-518: --- Summary: ToCDUCheck and ToCHRCheck: Value formatted as float instead of int (was: ToCDUCheck: Value formatted as float instead of int) > ToCDUCheck and ToCHRCheck: Value formatted as float instead of int > -- > > Key: TC-518 > URL: https://issues.apache.org/jira/browse/TC-518 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Steve Malenfant >Priority: Trivial > Fix For: 2.2.0 > > > CDU check return value are formatted as a float while the database values > were stored as int (mysql) and bigint (postgresql). > This check fails against 2.0+ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-514) ORT: Change Traffic Ops hostname in middle of ORT run
Steve Malenfant created TC-514:
--
Summary: 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
Environment: Traffic Ops 2.1 and ORT 2.1
Reporter: Steve Malenfant
Assignee: Derek Gelinas
Priority: Minor
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-0001.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-0001.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-0001.coxlab.net
...
INFO: Start processing packages
DEBUG Total connections in LWP cache: 1
INFO Traffic Ops host: https://traffic-ops-0002.coxlab.net
DEBUG lwp_get called with /ort/psp6cdedge06/packages
ERROR https://cdn1cdcms0001.coxlab.net/ort/edge06/packages returned HTTP 401!
Unauthorized
ERROR result for https://cdn1cdcms0001.coxlab.net/ort/psp6cdedge06/packages is:
[jira] [Created] (TC-512) Default cdn.conf should have a traffic_ops_golang_port defined
Steve Malenfant created TC-512: -- Summary: Default cdn.conf should have a traffic_ops_golang_port defined Key: TC-512 URL: https://issues.apache.org/jira/browse/TC-512 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Affects Versions: 2.1.0 Reporter: Steve Malenfant Priority: Trivial Postinstall handles adding traffic_ops_golang_port to the cdn.conf, but there is no example in the default cdn.conf. Almost documentation bug, but having some working defaults in cdn.conf is a good idea. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-511) migrations: Remove the reference to public table
Steve Malenfant created TC-511: -- Summary: migrations: Remove the reference to public table Key: TC-511 URL: https://issues.apache.org/jira/browse/TC-511 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Affects Versions: 2.1.0 Environment: Centos 7.3, Postgres 0.9.6 Reporter: Steve Malenfant Assignee: Steve Malenfant Priority: Minor Fix For: 2.1.0 The `20170205101432_cdn_table_domain_name.go` migration contains reference to some public tables and needs the description changed from "Starting migration 20130106222315". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-375) yum upgrade traffic_ops... can't find goose
[
https://issues.apache.org/jira/browse/TC-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123332#comment-16123332
]
Steve Malenfant commented on TC-375:
[~dewrich] I just tried upgrading from 2.0 to
traffic_ops-2.1.0-6795.e2e89e12.el7.x86_64.rpm and the same thing happened.
goose was in the path. Does the fix introduced take care of the 2.0 -> 2.1 RPM
upgrade?
{code:java}
Preparing... # [100%]
trafops:x:995:ansible
trafops:x:997:995::/opt/traffic_ops:/sbin/nologin
Backing up config files.
Stopping traffic_ops (via systemctl): [ OK ]
Updating / installing...
1:traffic_ops-2.1.0-6795.e2e89e12.ewarning:
/opt/traffic_ops/app/conf/cdn.conf created as
/opt/traffic_ops/app/conf/cdn.conf.rpmnew
# [ 50%]
Restoring config files.
Migrating database...
Can't exec "goose": No such file or directory at db/admin.pl line 183.
Can't run goose
Database migration failed.
Upgrade complete.
{code}
> yum upgrade traffic_ops... can't find goose
> ---
>
> Key: TC-375
> URL: https://issues.apache.org/jira/browse/TC-375
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>Assignee: Dewayne Richardson
> Labels: goose, postinstall, yum
> Fix For: 2.1.0
>
>
> Traffic Ops postinstall puts goose in /opt/traffic_ops/go/bin. The rpm
> upgrade path executes `db/admin.pl upgrade` which tries to run goose, but
> can't find it because it's not in the root PATH.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TC-151) Delivery Service XML IDs should be limited to lower-case letters
[ https://issues.apache.org/jira/browse/TC-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123271#comment-16123271 ] Steve Malenfant commented on TC-151: [~shemesh] Are we talking about the XML ID or the HOST_REGEXP? Maybe I'm wrong, but the XML ID is not part of the FQDN. > Delivery Service XML IDs should be limited to lower-case letters > > > Key: TC-151 > URL: https://issues.apache.org/jira/browse/TC-151 > Project: Traffic Control > Issue Type: New Feature > Components: Traffic Ops >Affects Versions: 1.7.0 >Reporter: Oren Shemesh >Priority: Minor > Labels: delivery_service, xml-id > > The DNS system is case-insensitive. Since a delivery service XML ID is used > as part of the FQDN of the cache being redirected to, two different DSs > cannot differ only by case. > This leads to the conclusion that it is best if we limit the XML IDs of > delivery services to be lower-case only. > This would achieve the following: > 1. Make domain names used by TC 'conventional' (i.e. lower-case only) > 2. Remove the possibility of a case-conflict between DSs > 3. Currently, Traffic Router does not behave correctly when a DS XML ID > contains upper case letters. Limiting to lower-case would prevent the need to > fix this :-) > Current problems with TR behaviour, when an XML ID contains opper-case letter > are: > 1. The TR sends a redirect to a host FQDN which contains a lower-case version > of the DS XML ID > 2. The TR does not resolve the lower-case version of the host FQDN. > Here is an example to demo current bug in TR. DS XML ID is opencachehub-DT, > TR redirects to opencachehub-dt, and then refused to resolve the cache name > using this DS (a lot of irrelevant data was removed fro this text): > $ curl -L -s -D - > http://tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com/video01.mp4 -v > * Connected to tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > (54.244.152.242) port 80 (#0) > > GET /video01.mp4 HTTP/1.1 > > Host: tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > > Accept: */* > > > < HTTP/1.1 302 Moved Temporarily > < Location: > http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4 > < Content-Length: 0 > < > * Connection #0 to host tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com left > intact > * Issue another request to this URL: > 'http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4' > * getaddrinfo(3) failed for > p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com:80 > * Couldn't resolve host > 'p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-57) Build process not changing directory and reading configuration file
[ https://issues.apache.org/jira/browse/TC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Malenfant closed TC-57. - > Build process not changing directory and reading configuration file > --- > > Key: TC-57 > URL: https://issues.apache.org/jira/browse/TC-57 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Monitor >Affects Versions: 1.9.0 > Environment: Vagrant + Centos 6.8 or Centos 7.2 >Reporter: Steve Malenfant >Assignee: Steve Malenfant >Priority: Minor > Labels: build > Fix For: 1.9.0 > > > Followed direction posted on the Traffic Monitor Developer’s Guide but I > couldn't seem to get Traffic Monitor test to work. > Using ~/build/build.sh fails to build Traffic Monitor > Using ~/build/build.sh traffic_monitor works but tests aren't working > Using cd traffic_monitor; ./build/build/build_rpm.sh seems to compile maven > but fails to find valid configuration file > I don't think I've successfully been able to run Traffic Monitor tests in the > past and my environment might be incorrect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-57) Build process not changing directory and reading configuration file
[ https://issues.apache.org/jira/browse/TC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Malenfant resolved TC-57. --- Resolution: Not A Bug Assignee: Steve Malenfant Fix Version/s: 1.9.0 > Build process not changing directory and reading configuration file > --- > > Key: TC-57 > URL: https://issues.apache.org/jira/browse/TC-57 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Monitor >Affects Versions: 1.9.0 > Environment: Vagrant + Centos 6.8 or Centos 7.2 >Reporter: Steve Malenfant >Assignee: Steve Malenfant >Priority: Minor > Labels: build > Fix For: 1.9.0 > > > Followed direction posted on the Traffic Monitor Developer’s Guide but I > couldn't seem to get Traffic Monitor test to work. > Using ~/build/build.sh fails to build Traffic Monitor > Using ~/build/build.sh traffic_monitor works but tests aren't working > Using cd traffic_monitor; ./build/build/build_rpm.sh seems to compile maven > but fails to find valid configuration file > I don't think I've successfully been able to run Traffic Monitor tests in the > past and my environment might be incorrect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-57) Build process not changing directory and reading configuration file
[ https://issues.apache.org/jira/browse/TC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121577#comment-16121577 ] Steve Malenfant commented on TC-57: --- This working fine now. You need to run './build/build.sh" from the root of the git directory. Looks like I was doing a "cd build" first. > Build process not changing directory and reading configuration file > --- > > Key: TC-57 > URL: https://issues.apache.org/jira/browse/TC-57 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Monitor >Affects Versions: 1.9.0 > Environment: Vagrant + Centos 6.8 or Centos 7.2 >Reporter: Steve Malenfant >Priority: Minor > Labels: build > > Followed direction posted on the Traffic Monitor Developer’s Guide but I > couldn't seem to get Traffic Monitor test to work. > Using ~/build/build.sh fails to build Traffic Monitor > Using ~/build/build.sh traffic_monitor works but tests aren't working > Using cd traffic_monitor; ./build/build/build_rpm.sh seems to compile maven > but fails to find valid configuration file > I don't think I've successfully been able to run Traffic Monitor tests in the > past and my environment might be incorrect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-368) /api/1.2/deliveryservices/:id/routing.json hangs when Traffic Router is unreachable
Steve Malenfant created TC-368: -- Summary: /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 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.3.15#6346)
[jira] [Created] (TC-353) Can't CNAME hostname with ccr"
Steve Malenfant created TC-353: -- Summary: Can't CNAME hostname with ccr" Key: TC-353 URL: https://issues.apache.org/jira/browse/TC-353 Project: Traffic Control Issue Type: Bug Reporter: Steve Malenfant -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TC-145) Re-add support for trafficserver 5.3.x to astats_over_http
[ https://issues.apache.org/jira/browse/TC-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Malenfant closed TC-145. -- > Re-add support for trafficserver 5.3.x to astats_over_http > -- > > Key: TC-145 > URL: https://issues.apache.org/jira/browse/TC-145 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Server Plugin - astats_over_http >Reporter: Steve Malenfant >Assignee: Steve Malenfant >Priority: Minor > Fix For: 2.0.0 > > > Latest commit to astats_over_http broke support for 5.3.x API. Will apply a > compile time defines to re-enable support. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TC-132) Some data not copied during sync TS database
[ https://issues.apache.org/jira/browse/TC-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Malenfant resolved TC-132. Resolution: Fixed Fix Version/s: 1.8.0 > Some data not copied during sync TS database > > > Key: TC-132 > URL: https://issues.apache.org/jira/browse/TC-132 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Stats >Reporter: Steve Malenfant >Assignee: Steve Malenfant >Priority: Minor > Fix For: 1.8.0 > > > The field max.kbps.ds.1day is part of the deliveryservice_stats table in the > "indefinite" retention policy. This one doesn't seem to be copied due to only > the "monthly" RP is used. > The daily_stats database doesn't specify the target RP during the copy which > causes influxDB 1.1 to write to "autogen". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TC-333) Mid Header Rewrite needs to be added to remap.config
Steve Malenfant created TC-333: -- Summary: Mid Header Rewrite needs to be added to remap.config Key: TC-333 URL: https://issues.apache.org/jira/browse/TC-333 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Reporter: Steve Malenfant Assignee: Jan van Doorn Priority: Minor Due to a mis-behaving origin, I want to override the Cache-Control (there isn't any in my case) using "Mid Header Rewrite". The delivery service feature does write the proper file to disk, but there is no remap rule set (basically doesn't do anything). The following map needs to be added when used: map http://originfqdn http://originfqdn @plugin=header_rewrite.so @pparam=hdr_rw_mid_.config Note: Missing header rewrite in the profile table is the root cause. Need to make sure they are added. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TC-264) Traffic Monitor Proxy should not be part of default parameter
Steve Malenfant created TC-264: -- Summary: Traffic Monitor Proxy should not be part of default parameter Key: TC-264 URL: https://issues.apache.org/jira/browse/TC-264 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Affects Versions: 1.8.0 Reporter: Steve Malenfant Priority: Minor During Traffic Portal integration, the API could not reach Traffic Ops. Found out during debugging session that the `tm.traffic_mon_fwd_proxy` parameter was defined as orphaned variable and was actually being used. Few things : 1 - This parameter is set at install as an orphan. 2 - This parameter is used even if not assigned to the GLOBAL profile 3 - The code is silent about the proxy not being reachable 4 - The documentation doesn't mention that parameter and which component uses it. I would suggest the following : 1 - Removed from default parameter install AND/OR 2) 2 - Add in the code that the profile "GLOBAL" needs assigned. Variable not assigned to a profile should not be used. 3 - Add logging to Traffic Ops (DEBUG at least) showing a proxy is being used and show the failed proxy requests 4 - Mention that profile parameter in the documentation -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TC-145) Re-add support for trafficserver 5.3.x to astats_over_http
Steve Malenfant created TC-145: -- Summary: Re-add support for trafficserver 5.3.x to astats_over_http Key: TC-145 URL: https://issues.apache.org/jira/browse/TC-145 Project: Traffic Control Issue Type: Bug Components: Traffic Server Plugin - astats_over_http Reporter: Steve Malenfant Assignee: Steve Malenfant Priority: Minor Latest commit to astats_over_http broke support for 5.3.x API. Will apply a compile time defines to re-enable support. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TC-108) sync_ts_database: Requires lots of memory to copy database
Steve Malenfant created TC-108: -- Summary: sync_ts_database: Requires lots of memory to copy database Key: TC-108 URL: https://issues.apache.org/jira/browse/TC-108 Project: Traffic Control Issue Type: Improvement Components: Traffic Stats Affects Versions: 1.8.0 Environment: 32GB server (about 20+GB available memory) running traffic_stats Reporter: Steve Malenfant Priority: Trivial During a migration from InfluxDB 0.13.3 to 1.1, we copied our entire database using the sync_ts_database. Somehow the process takes a long time due all memory+swap being used. As far as I know it doesn't get killed but the process seems to never finish (I'm probably being impatient after 30 minutes). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TC-57) Build process not changing directory and reading configuration file
Steve Malenfant created TC-57: - Summary: Build process not changing directory and reading configuration file Key: TC-57 URL: https://issues.apache.org/jira/browse/TC-57 Project: Traffic Control Issue Type: Bug Components: Traffic Monitor Affects Versions: 1.9.0 Environment: Vagrant + Centos 6.8 or Centos 7.2 Reporter: Steve Malenfant Priority: Minor Followed direction posted on the Traffic Monitor Developer’s Guide but I couldn't seem to get Traffic Monitor test to work. Using ~/build/build.sh fails to build Traffic Monitor Using ~/build/build.sh traffic_monitor works but tests aren't working Using cd traffic_monitor; ./build/build/build_rpm.sh seems to compile maven but fails to find valid configuration file I don't think I've successfully been able to run Traffic Monitor tests in the past and my environment might be incorrect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
