[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=16125628#comment-16125628 ] Oren Shemesh commented on TC-151: - [~hbeatty] I do not understand how can this b e described as not a bug. I just added two delivery services to TO, one with xml-id x1 and one with xml-id X1 (See image below). To two different delivery services, which differ by case only, are allowed by TO. I did not test, but since TR redirects to a lower-case version of the XML ID, it means that both these delivery services (I gave them two different host regexps) would be redirected to the same URL. I believe this cannot be good... Maybe I am missing something ? !screenshot-1.png! > 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 > Attachments: screenshot-1.png > > > The DNS system is case-insensitive. Since a delivery service XML ID is used > as part of the FQDN of the cache being redirected to, two different DSs > cannot differ only by case. > This leads to the conclusion that it is best if we limit the XML IDs of > delivery services to be lower-case only. > This would achieve the following: > 1. Make domain names used by TC 'conventional' (i.e. lower-case only) > 2. Remove the possibility of a case-conflict between DSs > 3. Currently, Traffic Router does not behave correctly when a DS XML ID > contains upper case letters. Limiting to lower-case would prevent the need to > fix this :-) > Current problems with TR behaviour, when an XML ID contains opper-case letter > are: > 1. The TR sends a redirect to a host FQDN which contains a lower-case version > of the DS XML ID > 2. The TR does not resolve the lower-case version of the host FQDN. > Here is an example to demo current bug in TR. DS XML ID is opencachehub-DT, > TR redirects to opencachehub-dt, and then refused to resolve the cache name > using this DS (a lot of irrelevant data was removed fro this text): > $ curl -L -s -D - > http://tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com/video01.mp4 -v > * Connected to tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > (54.244.152.242) port 80 (#0) > > GET /video01.mp4 HTTP/1.1 > > Host: tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > > Accept: */* > > > < HTTP/1.1 302 Moved Temporarily > < Location: > http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4 > < Content-Length: 0 > < > * Connection #0 to host tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com left > intact > * Issue another request to this URL: > 'http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4' > * getaddrinfo(3) failed for > p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com:80 > * Couldn't resolve host > 'p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-151) Delivery Service XML IDs should be limited to lower-case letters
[ https://issues.apache.org/jira/browse/TC-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oren Shemesh updated TC-151: Attachment: screenshot-1.png > 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 > Attachments: screenshot-1.png > > > The DNS system is case-insensitive. Since a delivery service XML ID is used > as part of the FQDN of the cache being redirected to, two different DSs > cannot differ only by case. > This leads to the conclusion that it is best if we limit the XML IDs of > delivery services to be lower-case only. > This would achieve the following: > 1. Make domain names used by TC 'conventional' (i.e. lower-case only) > 2. Remove the possibility of a case-conflict between DSs > 3. Currently, Traffic Router does not behave correctly when a DS XML ID > contains upper case letters. Limiting to lower-case would prevent the need to > fix this :-) > Current problems with TR behaviour, when an XML ID contains opper-case letter > are: > 1. The TR sends a redirect to a host FQDN which contains a lower-case version > of the DS XML ID > 2. The TR does not resolve the lower-case version of the host FQDN. > Here is an example to demo current bug in TR. DS XML ID is opencachehub-DT, > TR redirects to opencachehub-dt, and then refused to resolve the cache name > using this DS (a lot of irrelevant data was removed fro this text): > $ curl -L -s -D - > http://tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com/video01.mp4 -v > * Connected to tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > (54.244.152.242) port 80 (#0) > > GET /video01.mp4 HTTP/1.1 > > Host: tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > > Accept: */* > > > < HTTP/1.1 302 Moved Temporarily > < Location: > http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4 > < Content-Length: 0 > < > * Connection #0 to host tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com left > intact > * Issue another request to this URL: > 'http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4' > * getaddrinfo(3) failed for > p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com:80 > * Couldn't resolve host > 'p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TC-151) Delivery Service XML IDs should be limited to lower-case letters
[ https://issues.apache.org/jira/browse/TC-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125628#comment-16125628 ] Oren Shemesh edited comment on TC-151 at 8/14/17 12:51 PM: --- [~hbeatty] I do not understand how can this b e described as not a bug. I just added two delivery services to TO, one with xml-id x1 and one with xml-id X1 (See image below). So two different delivery services, which differ by case only, are allowed by TO. I did not test, but since TR redirects to a lower-case version of the XML ID, it means that both these delivery services (I gave them two different host regexps) would be redirected to the same URL. I believe this cannot be good... Maybe I am missing something ? !screenshot-1.png! was (Author: shemesh): [~hbeatty] I do not understand how can this b e described as not a bug. I just added two delivery services to TO, one with xml-id x1 and one with xml-id X1 (See image below). To two different delivery services, which differ by case only, are allowed by TO. I did not test, but since TR redirects to a lower-case version of the XML ID, it means that both these delivery services (I gave them two different host regexps) would be redirected to the same URL. I believe this cannot be good... Maybe I am missing something ? !screenshot-1.png! > 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 > Attachments: screenshot-1.png > > > The DNS system is case-insensitive. Since a delivery service XML ID is used > as part of the FQDN of the cache being redirected to, two different DSs > cannot differ only by case. > This leads to the conclusion that it is best if we limit the XML IDs of > delivery services to be lower-case only. > This would achieve the following: > 1. Make domain names used by TC 'conventional' (i.e. lower-case only) > 2. Remove the possibility of a case-conflict between DSs > 3. Currently, Traffic Router does not behave correctly when a DS XML ID > contains upper case letters. Limiting to lower-case would prevent the need to > fix this :-) > Current problems with TR behaviour, when an XML ID contains opper-case letter > are: > 1. The TR sends a redirect to a host FQDN which contains a lower-case version > of the DS XML ID > 2. The TR does not resolve the lower-case version of the host FQDN. > Here is an example to demo current bug in TR. DS XML ID is opencachehub-DT, > TR redirects to opencachehub-dt, and then refused to resolve the cache name > using this DS (a lot of irrelevant data was removed fro this text): > $ curl -L -s -D - > http://tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com/video01.mp4 -v > * Connected to tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > (54.244.152.242) port 80 (#0) > > GET /video01.mp4 HTTP/1.1 > > Host: tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com > > Accept: */* > > > < HTTP/1.1 302 Moved Temporarily > < Location: > http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4 > < Content-Length: 0 > < > * Connection #0 to host tr.opencachehub-DT.stage-cdn.tc-stage.cqloud.com left > intact > * Issue another request to this URL: > 'http://p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com/video01.mp4' > * getaddrinfo(3) failed for > p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com:80 > * Couldn't resolve host > 'p39-edge-lab.opencachehub-dt.stage-cdn.tc-stage.cqloud.com' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TC-351) Generate new SSL keys fails after a while
[
https://issues.apache.org/jira/browse/TC-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021281#comment-16021281
]
Oren Shemesh edited comment on TC-351 at 6/14/17 4:58 AM:
--
This is most probably a side effect of
[TC-158|https://issues.apache.org/jira/browse/TC-158], which is fixed only in
2.0.
So most probably TC-351 is fixed in 2.0 as well.
was (Author: shemesh):
This is probably the result of
[TC-158|https://issues.apache.org/jira/browse/TC-158], which is fixed only in
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
>
> 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] [Commented] (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:comment-tabpanel=16021281#comment-16021281
]
Oren Shemesh commented on TC-351:
-
This is probably the result of
[TC-158|https://issues.apache.org/jira/browse/TC-158], which is fixed only in
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
>
> 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.3.15#6346)
[jira] [Commented] (TC-251) DNSSEC keys refresh doesn't work
[ https://issues.apache.org/jira/browse/TC-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15990199#comment-15990199 ] Oren Shemesh commented on TC-251: - Jeremy, David and me discussed this, there was a bug in my fix to the email problem, which introduced the dnssec keys refresh problem. PR#523 fixes my bug, so now we have both a working email and a working dnssec keys refresh :-) > DNSSEC keys refresh doesn't work > > > Key: TC-251 > URL: https://issues.apache.org/jira/browse/TC-251 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.0.0, 2.1.0 >Reporter: David Neuman >Assignee: David Neuman > Fix For: 2.0.0, 2.1.0 > > > They DNSSEC keys route doesn't work. It never returns a reponse to the > client, so the client times out, and it also isn't actually updating the > expired keys. I think the client issues was introduced with changes to the > "fork_and_daemonize()" method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TC-158) daemonize() leaves parent process with bad SIGCHLD handler
[ https://issues.apache.org/jira/browse/TC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oren Shemesh resolved TC-158. - Resolution: Fixed Here is the commit that closes PR #295, which solves this issue: https://github.com/apache/incubator-trafficcontrol/commits/051d5f016e0bb8b5950bc6e28ebb27e48cf3a55e > daemonize() leaves parent process with bad SIGCHLD handler > -- > > Key: TC-158 > URL: https://issues.apache.org/jira/browse/TC-158 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 1.8.0, 2.0.0, 1.7.0 >Reporter: Oren Shemesh >Assignee: Oren Shemesh > Fix For: 2.0.0 > > > Daemon::daemonize() was created to allow a process to run sub-processes in > the background, without waiting for their immediate termination. > In order for terminated processes to be reaped and not become zombies, the > SIGCHLD handler in the parent should be set to IGNORE. > However, doing so in a standard process prevents it from reliably running > waitpid(), so many operations that involve forking and waiting for the forked > process return code (Such as: Sending e-mail, generating SSL keys, and any > functionality using UI::Utils->exec_command() ) become unreliable. > The problem is not easily noticed, since daemonize is currently called only > by API::Cdn::dnssec_keys_refresh(), which is being called twice every 5 > minutes. Since there are 96 TO workers by default, it takes a few hours until > most of the workers get contaminated with a bad SIGCHLD handler. > A proper solution is to use double forking in daemonize(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TC-158) daemonize() leaves parent process with bad SIGCHLD handler
Oren Shemesh created TC-158: --- Summary: daemonize() leaves parent process with bad SIGCHLD handler Key: TC-158 URL: https://issues.apache.org/jira/browse/TC-158 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Affects Versions: 1.8.0, 2.0.0, 1.7.0 Reporter: Oren Shemesh Assignee: Oren Shemesh Fix For: 2.0.0 Daemon::daemonize() was created to allow a process to run sub-processes in the background, without waiting for their immediate termination. In order for terminated processes to be reaped and not become zombies, the SIGCHLD handler in the parent should be set to IGNORE. However, doing so in a standard process prevents it from reliably running waitpid(), so many operations that involve forking and waiting for the forked process return code (Such as: Sending e-mail, generating SSL keys, and any functionality using UI::Utils->exec_command() ) become unreliable. The problem is not easily noticed, since daemonize is currently called only by API::Cdn::dnssec_keys_refresh(), which is being called twice every 5 minutes. Since there are 96 TO workers by default, it takes a few hours until most of the workers get contaminated with a bad SIGCHLD handler. A proper solution is to use double forking in daemonize(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TC-151) Delivery Service XML IDs should be limited to lower-case letters
Oren Shemesh created TC-151: --- Summary: Delivery Service XML IDs should be limited to lower-case letters Key: TC-151 URL: https://issues.apache.org/jira/browse/TC-151 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Affects Versions: 1.7.0 Reporter: Oren Shemesh Priority: Minor 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.3.15#6346)
[jira] [Resolved] (TC-142) traffic_ops/app/conf/production/influxdb.conf
[ https://issues.apache.org/jira/browse/TC-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oren Shemesh resolved TC-142. - Resolution: Fixed Fixed by PR #264 > traffic_ops/app/conf/production/influxdb.conf > - > > Key: TC-142 > URL: https://issues.apache.org/jira/browse/TC-142 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 1.8.0, 1.7.0, 1.9.0 > Environment: All >Reporter: Oren Shemesh >Assignee: Oren Shemesh >Priority: Minor > Fix For: 1.9.0 > > > According to > [DeliveryServiceStats.pm::get_db_name()|https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/API/DeliveryServiceStats.pm#L95], > the key holding the deliveryservice database name in influxDb is > "deliveryservice_stats_db_name". > The key and value found in > [production/influxdb.conf|https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/conf/production/influxdb.conf#L4] > are wrong. > The keys and values found at test/influxdb.conf and development/influxdb.conf > are good. > This code is used by the /api/1.2/deliveryservice_stats TO API, and prevented > DS graphs from being displayed in traffic portal > [PR #264|https://github.com/apache/incubator-trafficcontrol/pull/264] fixes > this -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TC-142) traffic_ops/app/conf/production/influxdb.conf
[ https://issues.apache.org/jira/browse/TC-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oren Shemesh updated TC-142: Description: According to [DeliveryServiceStats.pm::get_db_name()|https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/API/DeliveryServiceStats.pm#L95], the key holding the deliveryservice database name in influxDb is "deliveryservice_stats_db_name". The key and value found in [production/influxdb.conf|https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/conf/production/influxdb.conf#L4] are wrong. The keys and values found at test/influxdb.conf and development/influxdb.conf are good. This code is used by the /api/1.2/deliveryservice_stats TO API, and prevented DS graphs from being displayed in traffic portal was: According to [DeliveryServiceStats.pm::get_db_name()|https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/API/DeliveryServiceStats.pm#L95], the key holding the deliveryservice database name in influxDb is "deliveryservice_stats_db_name". The key and value found in [production/influxdb.conf|https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/conf/production/influxdb.conf#L4]are wrong. The keys and values found at test/influxdb.conf and development/influxdb.conf are good. This code is used by the /api/1.2/deliveryservice_stats TO API, and prevented DS graphs from being displayed in traffic portal > traffic_ops/app/conf/production/influxdb.conf > - > > Key: TC-142 > URL: https://issues.apache.org/jira/browse/TC-142 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 1.8.0, 1.7.0, 1.9.0 > Environment: All >Reporter: Oren Shemesh >Priority: Minor > Fix For: 1.9.0 > > > According to > [DeliveryServiceStats.pm::get_db_name()|https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/API/DeliveryServiceStats.pm#L95], > the key holding the deliveryservice database name in influxDb is > "deliveryservice_stats_db_name". > The key and value found in > [production/influxdb.conf|https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/conf/production/influxdb.conf#L4] > are wrong. > The keys and values found at test/influxdb.conf and development/influxdb.conf > are good. > This code is used by the /api/1.2/deliveryservice_stats TO API, and prevented > DS graphs from being displayed in traffic portal -- This message was sent by Atlassian JIRA (v6.3.15#6346)
