[jira] [Resolved] (TC-532) PUT /api/$version/deliveryservices/:id/safe needs to have tenancy check in place
[ https://issues.apache.org/jira/browse/TC-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dylan Volz resolved TC-532. --- Resolution: Fixed https://github.com/apache/incubator-trafficcontrol/pull/867 > PUT /api/$version/deliveryservices/:id/safe needs to have tenancy check in > place > > > Key: TC-532 > URL: https://issues.apache.org/jira/browse/TC-532 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell >Assignee: Dylan Volz > > 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. > PUT /api/$version/deliveryservices/:id/safe needs to check tenancy to ensure > users do not attempt to update ds's that they don't have access to. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-548) Determine how to handle hostname change for ssl keys
Dylan Volz created TC-548: - Summary: Determine how to handle hostname change for ssl keys Key: TC-548 URL: https://issues.apache.org/jira/browse/TC-548 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Reporter: Dylan Volz Now when a DS's hostname changes on an update, via UI or API, it changes the hostname field on the record stored in riak, but it does not regenerate the certificate or CSR so there will be a mismatch between the ssl certificate and the hostname it is being used for. We need to decide what the proper way to handle this is, we can regenerate the certificate and CSR in the manner we currently do from the api or ui but they will still be unsigned without human interaction at this point. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TC-547) Fix regression issues caused by TC-187
[ https://issues.apache.org/jira/browse/TC-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16137256#comment-16137256 ] Dylan Volz edited comment on TC-547 at 8/22/17 8:56 PM: PRs https://github.com/apache/incubator-trafficcontrol/pull/790 and https://github.com/apache/incubator-trafficcontrol/pull/853 are waiting on this issue, if you could comment on the PRs when this is merged it would be appreciated. was (Author: dylan_volz): PRS https://github.com/apache/incubator-trafficcontrol/pull/790 and https://github.com/apache/incubator-trafficcontrol/pull/853 are waiting on this issue, if you could comment on the PRs when this is merged it would be appreciated. > Fix regression issues caused by TC-187 > -- > > Key: TC-547 > URL: https://issues.apache.org/jira/browse/TC-547 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 3.0.0 >Reporter: Zhilin Huang >Assignee: Zhilin Huang > > Fix for TC-187 introduced change to use "ds_" instead of xml_id as the > key to put SSL certificate to riak server. > This may cause regression issues when doing migration. And as xml_id becomes > immutable now, this change is not needed anymore. > Also the change for get ssl certificate in API may cause regression issue. > Will revert it as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TC-547) Fix regression issues caused by TC-187
[ https://issues.apache.org/jira/browse/TC-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16137256#comment-16137256 ] Dylan Volz edited comment on TC-547 at 8/22/17 8:56 PM: PRS https://github.com/apache/incubator-trafficcontrol/pull/790 and https://github.com/apache/incubator-trafficcontrol/pull/853 are waiting on this issue, if you could comment on the PRs when this is merged it would be appreciated. was (Author: dylan_volz): PR https://github.com/apache/incubator-trafficcontrol/pull/790 is waiting on this issue, if you could comment on the PR when this is merged it would be appreciated. > Fix regression issues caused by TC-187 > -- > > Key: TC-547 > URL: https://issues.apache.org/jira/browse/TC-547 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 3.0.0 >Reporter: Zhilin Huang >Assignee: Zhilin Huang > > Fix for TC-187 introduced change to use "ds_" instead of xml_id as the > key to put SSL certificate to riak server. > This may cause regression issues when doing migration. And as xml_id becomes > immutable now, this change is not needed anymore. > Also the change for get ssl certificate in API may cause regression issue. > Will revert it as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-547) Fix regression issues caused by TC-187
[ https://issues.apache.org/jira/browse/TC-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16137256#comment-16137256 ] Dylan Volz commented on TC-547: --- PR https://github.com/apache/incubator-trafficcontrol/pull/790 is waiting on this issue, if you could comment on the PR when this is merged it would be appreciated. > Fix regression issues caused by TC-187 > -- > > Key: TC-547 > URL: https://issues.apache.org/jira/browse/TC-547 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 3.0.0 >Reporter: Zhilin Huang >Assignee: Zhilin Huang > > Fix for TC-187 introduced change to use "ds_" instead of xml_id as the > key to put SSL certificate to riak server. > This may cause regression issues when doing migration. And as xml_id becomes > immutable now, this change is not needed anymore. > Also the change for get ssl certificate in API may cause regression issue. > Will revert it as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-510) cannot apply ipv6 on delivery services
[
https://issues.apache.org/jira/browse/TC-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129081#comment-16129081
]
Dylan Volz commented on TC-510:
---
I believe this can be left for 2.2 because updating delivery services with ipv6
works via the api route, exercised via the new traffic portal. I verified this
today.
> 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] [Assigned] (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
]
Dylan Volz reassigned TC-510:
-
Assignee: Dylan Volz
> 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
>Reporter: Sean Aoyagi
>Assignee: Dylan Volz
>
> 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] [Resolved] (TC-336) Add ability to copy url_sig keys from one DS to another GH #1540
[ https://issues.apache.org/jira/browse/TC-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dylan Volz resolved TC-336. --- Resolution: Fixed > Add ability to copy url_sig keys from one DS to another GH #1540 > > > Key: TC-336 > URL: https://issues.apache.org/jira/browse/TC-336 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops, Traffic Vault >Reporter: Dewayne Richardson >Assignee: Dylan Volz >Priority: Minor > Labels: keys, url_signing > > There are some cases where we want to use the same URL sig keys for multiple > delivery services. Currently this is handled by using cURL and other manual > processes. Traffic Ops should support the ability to copy url sig keys from > one DS to another. When this happens Traffic Ops should also create the > necessary parameters for the target DS so that URL signing works. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-497) delivery service updates taking >20 secs
[
https://issues.apache.org/jira/browse/TC-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dylan Volz resolved TC-497.
---
Resolution: Fixed
> delivery service updates taking >20 secs
>
>
> Key: TC-497
> URL: https://issues.apache.org/jira/browse/TC-497
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Reporter: Dylan Volz
>Assignee: Dylan Volz
>
> delivery service updates have begun taking about 25 seconds to finish.
> I have tracked this down to this call:
> my $rs = $self->db->resultset('DeliveryserviceRegex')->search(undef,
> {prefetch => [
> {regex => undef}
> ,
> {deliveryservice => undef}
> ]} );
> in the find_existing_host_regex helper defined in
> MojoPlugins/DeliveryService.pm
> The worker is selected for graceful shutdown due to no heartbeat each time an
> update is made, but usually completes before the shutdown allowing the update
> to go through.
> If you add a second host regex to the delivery service the update will always
> fail because it makes that db call twice and thus the worker is killed before
> the request finishes, and the request is sent to a new worker, continuing the
> process until the browser cancels the request.
> Note: delivery service updates via the API do not have this problem because
> it appears that code path does not check for conflicting regexes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (TC-148) GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns pointer to Hash
[
https://issues.apache.org/jira/browse/TC-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dylan Volz resolved TC-148.
---
Resolution: Fixed
> GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns pointer to Hash
> --
>
> Key: TC-148
> URL: https://issues.apache.org/jira/browse/TC-148
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops, Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Dylan Volz
>Priority: Minor
> Labels: api_deliveryservices
>
> GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns, for example:
> {
> response: "HTTP::Response=HASH(0x6f9f018)"
> }
> instead of the actual json hash/object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=16120083#comment-16120083
]
Dylan Volz edited comment on TC-374 at 8/9/17 4:00 PM:
---
This means the processes were orphaned, and adopted by root (as expected) but
then never waited on (reaped). I happened to have just read about a similar
issue docker can have here:
https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/.
Seems that hypnotoad (wrapping Mojo::Server::Prefork) should be handling this
and it will require some digging, I think some tooling using
http://mojolicious.org/perldoc/Mojo/Server/Prefork#reap
and http://mojolicious.org/perldoc/Mojo/Server/Prefork#spawn may help
illuminate what is going on.
was (Author: dylan_volz):
This means the processes were orphaned, and adopted by root (as expected) but
then never waited on (reaped). I happened to have just read about a similar
issue docker can have here:
https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/
that describes it in detail and perhaps a similar solution can be applied in
our start up script.
> `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
> Labels: systemctl
> Fix For: 2.1.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] [Commented] (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:comment-tabpanel&focusedCommentId=16120083#comment-16120083
]
Dylan Volz commented on TC-374:
---
This means the processes were orphaned, and adopted by root (as expected) but
then never waited on (reaped). I happened to have just read about a similar
issue docker can have here:
https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/
that describes it in detail and perhaps a similar solution can be applied in
our start up script.
> `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
> Labels: systemctl
> Fix For: 2.1.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] [Commented] (TC-497) delivery service updates taking >20 secs
[
https://issues.apache.org/jira/browse/TC-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112994#comment-16112994
]
Dylan Volz commented on TC-497:
---
https://github.com/apache/incubator-trafficcontrol/pull/763 created
> delivery service updates taking >20 secs
>
>
> Key: TC-497
> URL: https://issues.apache.org/jira/browse/TC-497
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Reporter: Dylan Volz
>Assignee: Dylan Volz
>
> delivery service updates have begun taking about 25 seconds to finish.
> I have tracked this down to this call:
> my $rs = $self->db->resultset('DeliveryserviceRegex')->search(undef,
> {prefetch => [
> {regex => undef}
> ,
> {deliveryservice => undef}
> ]} );
> in the find_existing_host_regex helper defined in
> MojoPlugins/DeliveryService.pm
> The worker is selected for graceful shutdown due to no heartbeat each time an
> update is made, but usually completes before the shutdown allowing the update
> to go through.
> If you add a second host regex to the delivery service the update will always
> fail because it makes that db call twice and thus the worker is killed before
> the request finishes, and the request is sent to a new worker, continuing the
> process until the browser cancels the request.
> Note: delivery service updates via the API do not have this problem because
> it appears that code path does not check for conflicting regexes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-497) delivery service updates taking >20 secs
Dylan Volz created TC-497:
-
Summary: delivery service updates taking >20 secs
Key: TC-497
URL: https://issues.apache.org/jira/browse/TC-497
Project: Traffic Control
Issue Type: Bug
Components: Traffic Ops
Reporter: Dylan Volz
Assignee: Dylan Volz
delivery service updates have begun taking about 25 seconds to finish.
I have tracked this down to this call:
my $rs = $self->db->resultset('DeliveryserviceRegex')->search(undef, {prefetch
=> [
{regex => undef}
,
{deliveryservice => undef}
]} );
in the find_existing_host_regex helper defined in MojoPlugins/DeliveryService.pm
The worker is selected for graceful shutdown due to no heartbeat each time an
update is made, but usually completes before the shutdown allowing the update
to go through.
If you add a second host regex to the delivery service the update will always
fail because it makes that db call twice and thus the worker is killed before
the request finishes, and the request is sent to a new worker, continuing the
process until the browser cancels the request.
Note: delivery service updates via the API do not have this problem because it
appears that code path does not check for conflicting regexes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16111766#comment-16111766 ] Dylan Volz commented on TC-494: --- Initial investigation: the update in question makes 9600+ separate db queries for the clone. the majority of these come from the 3 calls to very similar methods in a loop over affected DSes: &UI::DeliveryService::header_rewrite &UI::DeliveryService::regex_remap &UI::DeliveryService::cacheurl Since all 3 use an almost identical logic pattern a simple rewrite to make a combined method could help lower the multiplier but I am not sure, without testing, how much this would move the needle. I think a more significant refactor may be needed to remove loops with db calls contained within and perhaps looking at changing our use of DBI to batch better. The other issue surfaced by this ticket is that since hypnotoad kills the worker that is blocked on IO the server assignments are broken since the delete goes first, again a refactor for transactions could be needed. This all said this seems like a strong candidate for a method to rewrite in golang pending: https://github.com/apache/incubator-trafficcontrol/pull/729 . > 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 >Reporter: Matt Mills >Assignee: Dylan Volz > > 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] [Assigned] (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 ] Dylan Volz reassigned TC-494: - Assignee: Dylan Volz > 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 >Reporter: Matt Mills >Assignee: Dylan Volz > > 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] [Created] (TC-456) develop assigned delivery service safe update endpoint
Dylan Volz created TC-456: - Summary: develop assigned delivery service safe update endpoint Key: TC-456 URL: https://issues.apache.org/jira/browse/TC-456 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Reporter: Dylan Volz Assignee: Dylan Volz Develop the api and ui functionality to allow users to update 4 fields on a delivery service assigned to them: display_name info_url long_desc long_desc_1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-148) GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns pointer to Hash
[
https://issues.apache.org/jira/browse/TC-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dylan Volz reassigned TC-148:
-
Assignee: Dylan Volz (was: Dan Kirkwood)
> GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns pointer to Hash
> --
>
> Key: TC-148
> URL: https://issues.apache.org/jira/browse/TC-148
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops, Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Dylan Volz
>Priority: Minor
> Labels: api_deliveryservices
>
> GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns, for example:
> {
> response: "HTTP::Response=HASH(0x6f9f018)"
> }
> instead of the actual json hash/object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (TC-386) Update traffic ops docker image
[ https://issues.apache.org/jira/browse/TC-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dylan Volz reassigned TC-386: - Assignee: Dylan Volz > Update traffic ops docker image > --- > > Key: TC-386 > URL: https://issues.apache.org/jira/browse/TC-386 > Project: Traffic Control > Issue Type: Task > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Dylan Volz >Assignee: Dylan Volz >Priority: Minor > > The traffic ops install process has changed and the docker image requires > updating to be usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-386) Update traffic ops docker image
Dylan Volz created TC-386: - Summary: Update traffic ops docker image Key: TC-386 URL: https://issues.apache.org/jira/browse/TC-386 Project: Traffic Control Issue Type: Task Components: Traffic Ops Affects Versions: 2.1.0 Reporter: Dylan Volz Priority: Minor The traffic ops install process has changed and the docker image requires updating to be usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
