[jira] [Resolved] (TC-532) PUT /api/$version/deliveryservices/:id/safe needs to have tenancy check in place

2017-08-28 Thread Dylan Volz (JIRA)

 [ 
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

2017-08-23 Thread Dylan Volz (JIRA)
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

2017-08-22 Thread Dylan Volz (JIRA)

[ 
https://issues.apache.org/jira/browse/TC-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2017-08-22 Thread Dylan Volz (JIRA)

[ 
https://issues.apache.org/jira/browse/TC-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2017-08-22 Thread Dylan Volz (JIRA)

[ 
https://issues.apache.org/jira/browse/TC-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2017-08-16 Thread Dylan Volz (JIRA)

[ 
https://issues.apache.org/jira/browse/TC-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Resolved] (TC-336) Add ability to copy url_sig keys from one DS to another GH #1540

2017-08-09 Thread Dylan Volz (JIRA)

 [ 
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-148) GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns pointer to Hash

2017-08-09 Thread Dylan Volz (JIRA)

 [ 
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

2017-08-09 Thread Dylan Volz (JIRA)

[ 
https://issues.apache.org/jira/browse/TC-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-497) delivery service updates taking >20 secs

2017-08-03 Thread Dylan Volz (JIRA)

[ 
https://issues.apache.org/jira/browse/TC-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2017-08-03 Thread Dylan Volz (JIRA)
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] [Assigned] (TC-494) Clone DS assignments button on Server times out

2017-08-02 Thread Dylan Volz (JIRA)

 [ 
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

2017-07-24 Thread Dylan Volz (JIRA)
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

2017-07-06 Thread Dylan Volz (JIRA)

 [ 
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

2017-06-13 Thread Dylan Volz (JIRA)

 [ 
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

2017-06-13 Thread Dylan Volz (JIRA)
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)