date:20170629

[jira] [Resolved] (TC-364) create ability to assign/remove delivery services to/from a user

2017-06-29 Thread Ryan Durfey (JIRA)


 [ 
https://issues.apache.org/jira/browse/TC-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey resolved TC-364.

Resolution: Fixed
  Assignee: Jeremy Mitchell

> create ability to assign/remove delivery services to/from a user
> 
>
> Key: TC-364
> URL: https://issues.apache.org/jira/browse/TC-364
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>  Labels: assignment, delivery_service, user
>
> Create api endpoints to:
> - assign 1 or more ds's to a user
> - remove a ds from a user
> - retrieve ds's not currently assigned to user
> these functions should be limited to the ops role or higher.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-275) Export/Import delivery service

2017-06-29 Thread Ryan Durfey (JIRA)


 [ 
https://issues.apache.org/jira/browse/TC-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey reassigned TC-275:
--

Assignee: Dylan Volz

> Export/Import delivery service
> --
>
> Key: TC-275
> URL: https://issues.apache.org/jira/browse/TC-275
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Matt Mills
>Assignee: Dylan Volz
>Priority: Minor
>  Labels: configuration, testing
>
> Feature Request, low priority.
> I'd like to be able to export/import delivery services so I can take an 
> entire delivery service from production into an alternate environment for 
> testing. It'd also need to be able to prompt you at import time for the 
> config components that don't line up between environments (if your profile 
> doesnt exist, select a new one, select new servers/cache groups for the DS to 
> be on).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TC-406) ORT incompatible with kernel version 4.9

2017-06-29 Thread Derek Gelinas (JIRA)

Derek Gelinas created TC-406:


 Summary: ORT incompatible with kernel version 4.9
 Key: TC-406
 URL: https://issues.apache.org/jira/browse/TC-406
 Project: Traffic Control
  Issue Type: Bug
  Components: Traffic Ops ORT
Reporter: Derek Gelinas
Assignee: Derek Gelinas
Priority: Minor


Kernel 4.9 adds a ".centos" after the el version, which the current regex 
cannot handle.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] incubator-trafficcontrol pull request #707: update ORT for kernel compatibil...

2017-06-29 Thread dg4prez

GitHub user dg4prez opened a pull request:

https://github.com/apache/incubator-trafficcontrol/pull/707

update ORT for kernel compatibility

Updates ORT for compatibility with the 4.9 kernel, which adds a ".centos" 
after the el version.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dg4prez/incubator-trafficcontrol 
ort_kernel_version

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafficcontrol/pull/707.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #707


commit b6dc3800292b08c059c5e522eeabb57799f155e6
Author: Derek Gelinas 
Date:   2017-06-29T19:16:51Z

update ORT for kernel compatibility




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-trafficcontrol pull request #644: Tenant utils

2017-06-29 Thread nir-sopher

Github user nir-sopher commented on a diff in the pull request:


https://github.com/apache/incubator-trafficcontrol/pull/644#discussion_r124880183
  
--- Diff: traffic_ops/app/lib/API/Tenant.pm ---
@@ -131,21 +130,74 @@ sub update {
 
my $is_active = $params->{active};

-   if ( !$params->{active} && $self->isRootTenant($id)) {
-   return $self->alert("Root user cannot be in-active.");
+   if ( !$params->{active} && $tenant_utils->is_root_tenant($tenants_data, 
$id)) {
+   return $self->alert("Root tenant cannot be in-active.");
+   }
+
+   #this is a write operation, allowed only by parents of the tenant 
(which are the owners of the resource of type tenant) 
+   my $current_resource_tenancy = $self->db->resultset('Tenant')->search( 
{ id => $id } )->get_column('parent_id')->single();
+   if (!defined($current_resource_tenancy)) {
+   #no parent - the tenant is its-own owner
+   $current_resource_tenancy = $id;
}

+   if (!$tenant_utils->is_tenant_resource_accessible($tenants_data, 
$current_resource_tenancy)) {
+   return $self->forbidden(); #Current owning tenant is not under 
user's tenancy
+   }
 
-   if ( !defined($params->{parentId}) && !isRootTenant($id) ) {
-   return $self->alert("Only the \"root\" tenant can have no 
parent.");
+   if (!$tenant_utils->is_tenant_resource_accessible($tenants_data, 
$params->{parentId})) {
+   return $self->forbidden(); #Parent tenant to be set is not 
under user's tenancy
}
+
+
+   if ($params->{parentId} != $tenant->parent) {
+   #parent replacement
+   if (!defined($tenant_utils->get_tenant_by_id($tenants_data, 
$params->{parentId}))) {
+   return $self->alert("Parent tenant does not exists.");
+   }
+   my $parent_depth = 
$tenant_utils->get_tenant_heirarchy_depth($tenants_data, $params->{parentId});
+   if (!defined($parent_depth))
+   {
+   return $self->alert("Failed to retrieve parent tenant 
depth.");
+   }
+
+   my $tenant_height = 
$tenant_utils->get_tenant_heirarchy_height($tenants_data, $id);
+   if (!defined($tenant_height))
+   {
+   return $self->alert("Failed to retrieve tenant 
height.");
+   }
+   
+   if ($parent_depth+$tenant_height+1 > 
$tenant_utils->max_heirarchy_limit())
--- End diff --

Indeed, safety nets may cover up bugs, but not in this case - the operation 
will fail instead of crashing or getting stuck. Then we can debug it.
Furthermore, we will have an error in the log pointing out the reason of 
the failure - what we will not have if we get into an infinite loop/recursion.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TC-346) 2.1 (master) Traffic Ops Installation issues.

2017-06-29 Thread Dan Kirkwood (JIRA)


[ 
https://issues.apache.org/jira/browse/TC-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068613#comment-16068613
 ] 

Dan Kirkwood commented on TC-346:
-

that same PR also fixes the other errors mentioned.   I think this can be 
closed.

> 2.1 (master) Traffic Ops Installation issues.
> -
>
> Key: TC-346
> URL: https://issues.apache.org/jira/browse/TC-346
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Jan van Doorn
>Assignee: Dewayne Richardson
>  Labels: installation
>
> Trying to install TO from scratch. Some notes:
> 1) had to install postgres stuff even though postgres is remote: 
> [jvando001@ipcdn-cache-28 tmp]$ sudo yum install postgresql
> [root@ipcdn-cache-28 ~]# yum install postgresql-devel
> 2) Some errors on the seeds, not sure if they matter: 
> {code} 
> === Setting up parameters
> Use of uninitialized value in concatenation (.) or string at 
> /opt/traffic_ops/install/bin/_postinstall line 638.
> Use of uninitialized value in concatenation (.) or string at 
> /opt/traffic_ops/install/bin/_postinstall line 638.
> -- global parameters
> insert into parameter (name, config_file, value)
> values ('tm.url', 'global', 'https://localhost')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value)
> values ('tm.instance_name', 'global', '')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value)
> values ('tm.toolname', 'global', '')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value)
> values ('tm.infourl', 'global', 'https://localhost/doc')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> -- CRConfig.json parameters
> insert into parameter (name, config_file, value)
> values ('geolocation.polling.url', 'CRConfig.json', 
> 'https://localhost/routing/GeoLite2-City.mmdb.gz')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value)
> values ('geolocation6.polling.url', 'CRConfig.json', 
> 'https://localhost/routing/GeoLiteCityv6.dat.gz')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> === Setting up profilesUse of uninitialized value in concatenation 
> (.) or string at /opt/traffic_ops/install/bin/_postinstall line 676.
> Use of uninitialized value in concatenation (.) or string at 
> /opt/traffic_ops/install/bin/_postinstall line 676.
> -- global parameters
> insert into profile (name, description, type)
> values ('GLOBAL', 'Global Traffic Ops profile, DO NOT 
> DELETE', 'UNK_PROFILE')
> ON CONFLICT (name) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'tm.url' and config_file = 'global' 
> and value = 'https://localhost') )
> ON CONFLICT (profile, parameter) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'tm.instance_name' and config_file = 
> 'global' and value = '') )
> ON CONFLICT (profile, parameter) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'tm.toolname' and config_file = 
> 'global' and value = '') )
> ON CONFLICT (profile, parameter) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'tm.infourl' and config_file = 
> 'global' and value = 'https://localhost/doc') )
> ON CONFLICT (profile, parameter) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'geolocation.polling.url' and 
> config_file = 'CRConfig.json' and value = 
> 'https://cdn1.denver-isp.org/routing/GeoLite2-City.mmdb.gz') )
> ON CONFLICT (profile, parameter) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'geolocation6.polling.url' and 
> config_file = 'CRConfig.json' and value = 
>

[jira] [Commented] (TC-346) 2.1 (master) Traffic Ops Installation issues.

2017-06-29 Thread Dan Kirkwood (JIRA)


[ 
https://issues.apache.org/jira/browse/TC-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068595#comment-16068595
 ] 

Dan Kirkwood commented on TC-346:
-

On original request:  "1) had to install postgres stuff even though postgres is 
remote: "

True -- postgresql96 and postgresql96-devel packages are required,  but not 
postgresql96-server.

postgresql96 provides psql command line tool for admin.pl to access the db.  
postgresql96-devel provides the libraries mojolicious needs to access the db.   
These are both now included as requirements in the rpm,  so are automatically 
installed: https://github.com/apache/incubator-trafficcontrol/pull/597


> 2.1 (master) Traffic Ops Installation issues.
> -
>
> Key: TC-346
> URL: https://issues.apache.org/jira/browse/TC-346
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Jan van Doorn
>Assignee: Dewayne Richardson
>  Labels: installation
>
> Trying to install TO from scratch. Some notes:
> 1) had to install postgres stuff even though postgres is remote: 
> [jvando001@ipcdn-cache-28 tmp]$ sudo yum install postgresql
> [root@ipcdn-cache-28 ~]# yum install postgresql-devel
> 2) Some errors on the seeds, not sure if they matter: 
> {code} 
> === Setting up parameters
> Use of uninitialized value in concatenation (.) or string at 
> /opt/traffic_ops/install/bin/_postinstall line 638.
> Use of uninitialized value in concatenation (.) or string at 
> /opt/traffic_ops/install/bin/_postinstall line 638.
> -- global parameters
> insert into parameter (name, config_file, value)
> values ('tm.url', 'global', 'https://localhost')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value)
> values ('tm.instance_name', 'global', '')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value)
> values ('tm.toolname', 'global', '')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value)
> values ('tm.infourl', 'global', 'https://localhost/doc')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> -- CRConfig.json parameters
> insert into parameter (name, config_file, value)
> values ('geolocation.polling.url', 'CRConfig.json', 
> 'https://localhost/routing/GeoLite2-City.mmdb.gz')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> insert into parameter (name, config_file, value)
> values ('geolocation6.polling.url', 'CRConfig.json', 
> 'https://localhost/routing/GeoLiteCityv6.dat.gz')
> ON CONFLICT (name, config_file, value) DO NOTHING;
> === Setting up profilesUse of uninitialized value in concatenation 
> (.) or string at /opt/traffic_ops/install/bin/_postinstall line 676.
> Use of uninitialized value in concatenation (.) or string at 
> /opt/traffic_ops/install/bin/_postinstall line 676.
> -- global parameters
> insert into profile (name, description, type)
> values ('GLOBAL', 'Global Traffic Ops profile, DO NOT 
> DELETE', 'UNK_PROFILE')
> ON CONFLICT (name) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'tm.url' and config_file = 'global' 
> and value = 'https://localhost') )
> ON CONFLICT (profile, parameter) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'tm.instance_name' and config_file = 
> 'global' and value = '') )
> ON CONFLICT (profile, parameter) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'tm.toolname' and config_file = 
> 'global' and value = '') )
> ON CONFLICT (profile, parameter) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'tm.infourl' and config_file = 
> 'global' and value = 'https://localhost/doc') )
> ON CONFLICT (profile, parameter) DO NOTHING;
> insert into profile_parameter (profile, parameter)
> values ( (select id from profile where name = 'GLOBAL'), 
> (select id from parameter where name = 'geolocation.polling.url' and 
> config_file

[jira] [Closed] (TC-259) crash when adding new delivery service thru UI

2017-06-29 Thread Dan Kirkwood (JIRA)


 [ 
https://issues.apache.org/jira/browse/TC-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Kirkwood closed TC-259.
---
Resolution: Fixed


This was fixed by https://github.com/apache/incubator-trafficcontrol/pull/539

> crash when adding new delivery service thru UI
> --
>
> Key: TC-259
> URL: https://issues.apache.org/jira/browse/TC-259
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
> Fix For: 2.1.0
>
>
> on `Delivery Services` page, click `Add new Delivery Service`,  I get this 
> error:
>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.
> Note this is in a dev environment with `setup_kabletown.pl` integration 
> fixtures loaded using the modified version from 
> https://github.com/apache/incubator-trafficcontrol/pull/528



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-404) ./pkg should show where resulting logs and artifacts were placed

2017-06-29 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TC-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068564#comment-16068564
 ] 

ASF GitHub Bot commented on TC-404:
---

GitHub user dangogh opened a pull request:

https://github.com/apache/incubator-trafficcontrol/pull/706

[TC-404] list artifacts when done building



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dangogh/incubator-trafficcontrol 
list-artifacts

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafficcontrol/pull/706.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #706


commit 0a502a25193a5bd7f05fc3952c54f364f78e5ecf
Author: Dan Kirkwood 
Date:   2017-06-29T15:58:20Z

list artifacts




> ./pkg should show where resulting logs and artifacts were placed
> 
>
> Key: TC-404
> URL: https://issues.apache.org/jira/browse/TC-404
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: All
>Affects Versions: 2.0.0
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
> Fix For: 2.1.0
>
>
> ./pkg without -v option only prints out "Building ..." messages.   At the 
> end,  it should list the contents of the "dist" directory to make it obvious 
> where rpm artifacts and log files were placed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (TC-404) ./pkg should show where resulting logs and artifacts were placed

2017-06-29 Thread Dan Kirkwood (JIRA)


 [ 
https://issues.apache.org/jira/browse/TC-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Kirkwood reassigned TC-404:
---

Assignee: Dan Kirkwood

> ./pkg should show where resulting logs and artifacts were placed
> 
>
> Key: TC-404
> URL: https://issues.apache.org/jira/browse/TC-404
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: All
>Affects Versions: 2.0.0
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
> Fix For: 2.1.0
>
>
> ./pkg without -v option only prints out "Building ..." messages.   At the 
> end,  it should list the contents of the "dist" directory to make it obvious 
> where rpm artifacts and log files were placed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-402) xml_id should not be changed after initial Delivery Service Creation

2017-06-29 Thread Jeremy Mitchell (JIRA)


[ 
https://issues.apache.org/jira/browse/TC-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068481#comment-16068481
 ] 

Jeremy Mitchell commented on TC-402:


Making the xml_id immutable was also decided in this email thread:

https://lists.apache.org/thread.html/fd4b4039ddc67521cb02440a30972a4103542b5cf86c7a86003c8371@%3Cdev.trafficcontrol.apache.org%3E

> xml_id should not be changed after initial Delivery Service Creation
> 
>
> Key: TC-402
> URL: https://issues.apache.org/jira/browse/TC-402
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Dewayne Richardson
>
> Traffic Ops cannot handle changing the xml_id because the parameters for the 
> ATS config files use the xml_id by naming convention.
> Easy fix, just disable the 'xml_id' field for "Edit/Updates"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-386) Docker Image for Traffic Ops Update

2017-06-29 Thread Ryan Durfey (JIRA)


 [ 
https://issues.apache.org/jira/browse/TC-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-386:
---
Summary: Docker Image for Traffic Ops Update  (was: Update traffic ops 
docker image)

> Docker Image for Traffic Ops Update
> ---
>
> 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
>  Labels: build, docker
>
> 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] [Updated] (TC-387) Max IP Address in DNS Answer - Make Dynamic based on Traffic Load

2017-06-29 Thread Ryan Durfey (JIRA)


 [ 
https://issues.apache.org/jira/browse/TC-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-387:
---
Description: 
Currently when we build a DNS routed service there is a parameter assigned 
called maximum IP address which determines how many cache IPs in each cache 
group should be handed out to the DNS system for the client.  This determines 
the number of caches across which content is assigned. For small services we 
typically assign 1-2 caches for larger services we assign 3-5 caches.  

This is currently done manually and if a service grows rapidly they could be 
handling a large volume of traffic and only have one cache in each group 
assigned.

I would like to consider some type of feedback loop which gages the popularity 
of a service and dynamically adjusts the number of cache IPs handed out. 

We should also consider splitting up this behavior of tying DNS address hand 
out to the number of caches across which we hash content.   These should be 
separate configuration and only the number of caches to hash across needs to be 
dynamic.

  was:
Currently when we build a DNS routed service there is a parameter assigned 
called maximum IP address which determines how many cache IPs in each cache 
group should be handed out to the DNS system for the client.  This determines 
the number of caches across which content is assigned. For small services we 
typically assign 1-2 caches for larger services we assign 3-5 caches.  

This is currently done manually and if a service grows rapidly they could be 
handling a large volume of traffic and only have one cache in each group 
assigned.

I would like to consider some type of feedback loop which gages the popularity 
of a service and dynamically adjusts the number of cache IPs handed out. 

Summary: Max IP Address in DNS Answer - Make Dynamic based on Traffic 
Load  (was: Dynamic assignment of max-ip address in DNS answer parameter for 
DNS routed services)

> Max IP Address in DNS Answer - Make Dynamic based on Traffic Load
> -
>
> Key: TC-387
> URL: https://issues.apache.org/jira/browse/TC-387
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Router
>Reporter: Ryan Durfey
>Assignee: Jeff Elsloo
>  Labels: dns, routing
>
> Currently when we build a DNS routed service there is a parameter assigned 
> called maximum IP address which determines how many cache IPs in each cache 
> group should be handed out to the DNS system for the client.  This determines 
> the number of caches across which content is assigned. For small services we 
> typically assign 1-2 caches for larger services we assign 3-5 caches.  
> This is currently done manually and if a service grows rapidly they could be 
> handling a large volume of traffic and only have one cache in each group 
> assigned.
> I would like to consider some type of feedback loop which gages the 
> popularity of a service and dynamically adjusts the number of cache IPs 
> handed out. 
> We should also consider splitting up this behavior of tying DNS address hand 
> out to the number of caches across which we hash content.   These should be 
> separate configuration and only the number of caches to hash across needs to 
> be dynamic.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TC-388) Max IP Address in DNS Answer - Default Behavior Change

2017-06-29 Thread Ryan Durfey (JIRA)


 [ 
https://issues.apache.org/jira/browse/TC-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Durfey updated TC-388:
---
Summary: Max IP Address in DNS Answer - Default Behavior Change  (was: Max 
IP Address in DNS Answer Behavior Change)

> Max IP Address in DNS Answer - Default Behavior Change
> --
>
> Key: TC-388
> URL: https://issues.apache.org/jira/browse/TC-388
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Router
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>  Labels: dns, routing
>
> The current default configuration for "Maximum IP addresses in DNS answer" is 
> zero  which causes the Traffic Router to return all IP addresses in  a cache 
> group to the DNS system for a client.  As cache groups grow beyond ~20 caches 
> the responses get too long for some networks and clients to handle. We have 
> seen specific instances where this breaks on the Verizon network.
> I suggest we make the default some lower but reasonable number that works in 
> most cases like "3".  This is a better default that would work for most small 
> to mid size services.  Savvy users who know to change this would be 
> unaffected. But this could save lots of errors for inexperienced users.
> I would also suggest that we consider an upper bound limitation like "10" for 
> at least a warning to users trying to configure a hire number.  If you have 
> to assign more than this then we should consider decoupling the number of IPs 
> returned from the number of servers that content is hashed across.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TC-402) xml_id should not be changed after initial Delivery Service Creation

2017-06-29 Thread Jeremy Mitchell (JIRA)


[ 
https://issues.apache.org/jira/browse/TC-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068413#comment-16068413
 ] 

Jeremy Mitchell commented on TC-402:


don't forget the API needs to be changed as well. specifically in this method:

https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Deliveryservice.pm#L262

> xml_id should not be changed after initial Delivery Service Creation
> 
>
> Key: TC-402
> URL: https://issues.apache.org/jira/browse/TC-402
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Dewayne Richardson
>
> Traffic Ops cannot handle changing the xml_id because the parameters for the 
> ATS config files use the xml_id by naming convention.
> Easy fix, just disable the 'xml_id' field for "Edit/Updates"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] incubator-trafficcontrol pull request #644: Tenant utils

2017-06-29 Thread mitchell852

Github user mitchell852 commented on a diff in the pull request:


https://github.com/apache/incubator-trafficcontrol/pull/644#discussion_r124806475
  
--- Diff: traffic_ops/app/lib/API/Tenant.pm ---
@@ -131,21 +130,74 @@ sub update {
 
my $is_active = $params->{active};

-   if ( !$params->{active} && $self->isRootTenant($id)) {
-   return $self->alert("Root user cannot be in-active.");
+   if ( !$params->{active} && $tenant_utils->is_root_tenant($tenants_data, 
$id)) {
+   return $self->alert("Root tenant cannot be in-active.");
+   }
+
+   #this is a write operation, allowed only by parents of the tenant 
(which are the owners of the resource of type tenant) 
+   my $current_resource_tenancy = $self->db->resultset('Tenant')->search( 
{ id => $id } )->get_column('parent_id')->single();
+   if (!defined($current_resource_tenancy)) {
+   #no parent - the tenant is its-own owner
+   $current_resource_tenancy = $id;
}

+   if (!$tenant_utils->is_tenant_resource_accessible($tenants_data, 
$current_resource_tenancy)) {
+   return $self->forbidden(); #Current owning tenant is not under 
user's tenancy
+   }
 
-   if ( !defined($params->{parentId}) && !isRootTenant($id) ) {
-   return $self->alert("Only the \"root\" tenant can have no 
parent.");
+   if (!$tenant_utils->is_tenant_resource_accessible($tenants_data, 
$params->{parentId})) {
+   return $self->forbidden(); #Parent tenant to be set is not 
under user's tenancy
}
+
+
+   if ($params->{parentId} != $tenant->parent) {
+   #parent replacement
+   if (!defined($tenant_utils->get_tenant_by_id($tenants_data, 
$params->{parentId}))) {
+   return $self->alert("Parent tenant does not exists.");
+   }
+   my $parent_depth = 
$tenant_utils->get_tenant_heirarchy_depth($tenants_data, $params->{parentId});
+   if (!defined($parent_depth))
+   {
+   return $self->alert("Failed to retrieve parent tenant 
depth.");
+   }
+
+   my $tenant_height = 
$tenant_utils->get_tenant_heirarchy_height($tenants_data, $id);
+   if (!defined($tenant_height))
+   {
+   return $self->alert("Failed to retrieve tenant 
height.");
+   }
+   
+   if ($parent_depth+$tenant_height+1 > 
$tenant_utils->max_heirarchy_limit())
--- End diff --

inside your is_ancestor function, you probably need a recursive function to 
walk down the tree starting with the tenant to be updated to ensure that the 
new parent is != self or child.

so your function call would look like this

if (!is_ancestor($tenant, $parent)) return $self->alert("Invalid parent")

here's an article regarding recursion in perl: 
https://perlmaven.com/recursive-subroutines


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Closed] (TC-272) ORT should ignore STEERING deliveryservices

2017-06-29 Thread Derek Gelinas (JIRA)


 [ 
https://issues.apache.org/jira/browse/TC-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Derek Gelinas closed TC-272.

   Resolution: Fixed
Fix Version/s: 2.1.0

> ORT should ignore STEERING deliveryservices
> ---
>
> Key: TC-272
> URL: https://issues.apache.org/jira/browse/TC-272
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops ORT
>Affects Versions: 2.1.0
>Reporter: David Neuman
>Assignee: Derek Gelinas
>  Labels: configuration, steering
> Fix For: 2.1.0
>
>
> With the 2.1 version of Traffic ops ORT, ORT grabs all of the configurations 
> for all of the Delivery services in a CDN and puts it on all caches in the 
> CDN regardless of DS Type and DS server assignments.   This causes an issue 
> with Steering deliveryservice because A) steering DSs shouldn't be on the 
> caches and B) steering DSs are created with certs that start with `ccr.` and 
> ORT does not know how to find those certificates in Traffic Vault which 
> causes ORT to fail.
> ORT should be updated such that Steering delivery service configurations are 
> not put on caches. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] incubator-trafficcontrol issue #644: Tenant utils

2017-06-29 Thread nir-sopher

Github user nir-sopher commented on the issue:

https://github.com/apache/incubator-trafficcontrol/pull/644
  
file move moved as required


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (TC-364) create ability to assign/remove delivery services to/from a user

[jira] [Assigned] (TC-275) Export/Import delivery service

[jira] [Created] (TC-406) ORT incompatible with kernel version 4.9

[GitHub] incubator-trafficcontrol pull request #707: update ORT for kernel compatibil...

[GitHub] incubator-trafficcontrol pull request #644: Tenant utils

[jira] [Commented] (TC-346) 2.1 (master) Traffic Ops Installation issues.

[jira] [Commented] (TC-346) 2.1 (master) Traffic Ops Installation issues.

[jira] [Closed] (TC-259) crash when adding new delivery service thru UI

[jira] [Commented] (TC-404) ./pkg should show where resulting logs and artifacts were placed

[jira] [Assigned] (TC-404) ./pkg should show where resulting logs and artifacts were placed

[jira] [Commented] (TC-402) xml_id should not be changed after initial Delivery Service Creation

[jira] [Updated] (TC-386) Docker Image for Traffic Ops Update

[jira] [Updated] (TC-387) Max IP Address in DNS Answer - Make Dynamic based on Traffic Load

[jira] [Updated] (TC-388) Max IP Address in DNS Answer - Default Behavior Change

[jira] [Commented] (TC-402) xml_id should not be changed after initial Delivery Service Creation

[GitHub] incubator-trafficcontrol pull request #644: Tenant utils

[jira] [Closed] (TC-272) ORT should ignore STEERING deliveryservices

[GitHub] incubator-trafficcontrol issue #644: Tenant utils

18 matches

Site Navigation

Mail list logo

Footer information