[jira] [Comment Edited] (TC-351) Generate new SSL keys fails after a while

[Oren Shemesh (JIRA)]

[ 
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] [Created] (TC-390) Update package structure for Traffic Router

[David Neuman (JIRA)]

David Neuman created TC-390:
---

 Summary: Update package structure for Traffic Router
 Key: TC-390
 URL: https://issues.apache.org/jira/browse/TC-390
 Project: Traffic Control
  Issue Type: Bug
  Components: Traffic Router
Reporter: David Neuman
Priority: Minor


Traffic Router's package structure is currently 
com.comcast.cdn.traffic_control.traffic_router, since we have moved to apache 
it should be org.apache.traffic_control.traffic_router.



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

[GitHub] incubator-trafficcontrol pull request #674: [BACKPORT] Introduces a new top-...

[dewrich]

GitHub user dewrich opened a pull request:

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

[BACKPORT] Introduces a new top-level TC project (traffic_ops_db) for 
managing the Traffic Ops Database

Initial PR #573

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

$ git pull https://github.com/dewrich/incubator-trafficcontrol 2.0.x

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

https://github.com/apache/incubator-trafficcontrol/pull/674.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 #674


commit 82521bec224935021726514aa8544a4c39988895
Author: Dewayne Richardson 
Date:   2017-05-11T17:06:00Z

initial version of the traffic_ops_db top level project

(cherry picked from commit ac0d7d761cfe8266a39e53d7687598f03eb8fdb7)

commit 8724636eb1f18ef71ffdc8036677960dc94dff16
Author: Dewayne Richardson 
Date:   2017-05-11T21:11:47Z

added installer for the Postgres Docker service-a

(cherry picked from commit e4872fdf24ab0dd464933e5866bd04848dabbf11)

commit bde8cabc6771109904d5f2e46b432f7357fbc20b
Author: Dewayne Richardson 
Date:   2017-05-11T21:11:48Z

added installer for the Postgres Docker service

(cherry picked from commit c0157f5374488cb194666e89e70819f09c537f5e)

commit 664c0ca196df6f64fb8ceb6f3b7760f776378821
Author: Dewayne Richardson 
Date:   2017-05-14T14:09:24Z

added cleanup for the waiter container

(cherry picked from commit 72ca7cfce02b068068df5ee72e8d5bcb834c2d60)




---
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] [Updated] (TC-228) postinstall changes needed for postgres

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-228:
---
 Labels: postgres postinstall  (was: )
Summary: postinstall changes needed for postgres  (was: TO: postinstall 
changes needed for postgres)

> postinstall changes needed for postgres
> ---
>
> Key: TC-228
> URL: https://issues.apache.org/jira/browse/TC-228
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
>  Labels: postgres, postinstall
> Fix For: 2.0.0
>
>
> more changes needed to get postinstall working correctly for a postgres 
> installation.
> This is needed for 2.0.x release.



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

[jira] [Updated] (TC-239) Validation rules for delivery service regex

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-239:
---
Labels: api_deliveryservices configuration host_regex validation  (was: 
configuration regex validation)

> Validation rules for delivery service regex
> ---
>
> Key: TC-239
> URL: https://issues.apache.org/jira/browse/TC-239
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Jeremy Mitchell
>  Labels: api_deliveryservices, configuration, host_regex, 
> validation
> Fix For: 2.1.0
>
>
> The following rules need to be enforced in the deliveryservice regex apis:
> 1. POST /api/../deliveryservices/:dsId/regexes (create ds regex)
> - you can't create a ds regex at position 0 because it was already created 
> for you when you created the ds and there can only be 1 regex at position 0.
> 2. PUT /api/../deliveryservices/:dsId/regexes/:id (update ds regex)
> - can't edit a ds regex to have set_number=0 (there can only be one and it 
> already exists)
> - can't update the set_number of the regex at position zero. 
> - the format of the ds regex at position zero must be validated to 
> .**\something\..**
> - if the pattern of the regex at position zero changes, then dnssec keys must 
> be recreated if the ds is part of a dnssecenabled cdn
> 3. DELETE /api/../deliveryservices/:dsId/regexes/:id (delete ds regex)
> - can't delete the regex at position zero



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

[jira] [Updated] (TC-242) tm_user.username and role should be NOT NULL in the db

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-242:
---
Summary: tm_user.username and role should be NOT NULL in the db  (was: TO - 
tm_user.username and role should be NOT NULL in the db)

> tm_user.username and role should be NOT NULL in the db
> --
>
> Key: TC-242
> URL: https://issues.apache.org/jira/browse/TC-242
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: configuration, tm_user.username, validation
> Fix For: 2.1.0
>
>
> username and role are 2 essential pieces of a user, therefore, the database 
> should enforce their existence.



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

[jira] [Updated] (TC-242) tm_user.username and role should be NOT NULL in the db

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-242:
---
Labels: configuration tm_user.username validation  (was: )

> tm_user.username and role should be NOT NULL in the db
> --
>
> Key: TC-242
> URL: https://issues.apache.org/jira/browse/TC-242
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: configuration, tm_user.username, validation
> Fix For: 2.1.0
>
>
> username and role are 2 essential pieces of a user, therefore, the database 
> should enforce their existence.



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

[jira] [Updated] (TC-247) Upgrading Traffic Ops via yum, goose is failing to execute

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-247:
---
Labels: goose yum  (was: )

> Upgrading Traffic Ops via yum, goose is failing to execute
> --
>
> Key: TC-247
> URL: https://issues.apache.org/jira/browse/TC-247
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Robert Scrimo
>  Labels: goose, yum
>
> When upgrading to Traffic Ops 2.1.0-6027.a62b5f9f.el7 via yum on Centos 7.2 
> the upgrade fails to run goose as per:
> -bash-4.2$ sudo yum upgrade traffic_ops
> Loaded plugins: fastestmirror
> atlas-client-ODOL_NOARCH  
>   | 2.3 kB  00:00:00
> atlas-client-ODOL_REPO
>   | 2.3 kB  00:00:00
> atlas-client-ODOL_REPO_GLOBAL 
>   | 2.3 kB  00:00:00
> atlas-client-ODOL_REPO_NOARCH 
>   | 2.3 kB  00:00:00
> comcast-atlas-centos_epel 
>   | 4.3 kB  00:00:00
> comcast-atlas-centos_x86_64   
>   | 2.5 kB  00:00:00
> docker-public 
>   | 2.9 kB  00:00:00
> traffic-control-Addons
>   | 1.3 kB  00:00:00
> traffic-control-Addons/primary
>   |  31 kB  00:00:00
> Loading mirror speeds from cached hostfile
> traffic-control-Addons
>  105/105
> Resolving Dependencies
> --> Running transaction check
> ---> Package traffic_ops.x86_64 0:2.1.0-5518.46e1f46a.el6 will be updated
> ---> Package traffic_ops.x86_64 0:2.1.0-6027.a62b5f9f.el7 will be an update
> --> Finished Dependency Resolution
> Dependencies Resolved
> ===
>  Package  ArchVersion 
>Repository   Size
> ===
> Updating:
>  traffic_ops  x86_64  2.1.0-6027.a62b5f9f.el7 
>traffic-control-Addons  875 k
> Transaction Summary
> ===
> Upgrade  1 Package
> Total download size: 875 k
> Is this ok [y/d/N]: y
> Downloading packages:
> Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
> traffic_ops-2.1.0-6027.a62b5f9f.el7.x86_64.rpm
>   | 875 kB  00:00:00
> Running transaction check
> Running transaction test
> Transaction test succeeded
> Running transaction
> trafops:x:994:
> trafops:x:997:994::/opt/traffic_ops:/sbin/nologin
> Backing up config files.
> tar: app/public/*Snapshots: Cannot stat: No such file or directory
> tar: Exiting with failure status due to previous errors
> Stopping traffic_ops (via systemctl):  [  OK  ]
>   Updating   : traffic_ops-2.1.0-6027.a62b5f9f.el7.x86_64 
>  1/2
> warning: /opt/traffic_ops/app/conf/cdn.conf created as 
> /opt/traffic_ops/app/conf/cdn.conf.rpmnew
> warning: /opt/traffic_ops/app/conf/production/database.conf created as 
> /opt/traffic_ops/app/conf/production/database.conf.rpmnew
> warning: /opt/traffic_ops/app/conf/production/log4perl.conf created as 
> /opt/traffic_ops/app/conf/production/log4perl.conf.rpmnew
> warning: /opt/traffic_ops/app/conf/production/riak.conf created as 
> /opt/traffic_ops/app/conf/production/riak.conf.rpmnew
> Restoring config files.
> Migrating database...
> Can't exec "goose": No such file or directory at db/admin.pl line 177.
> Can't run goose
> Database migration failed.
> Upgrade complete.
> Run /opt/traffic_ops/install/bin/postinstall from the root home directory to 
> complete the update.
> To start 

[jira] [Updated] (TC-250) RPM tries to back up nonexistent on-disk CRConfigs

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-250:
---
 Labels: crconfig rpm  (was: )
Summary: RPM tries to back up nonexistent on-disk CRConfigs  (was: Traffic 
Ops RPM tries to back up nonexistent on-disk CRConfigs)

> RPM tries to back up nonexistent on-disk CRConfigs
> --
>
> Key: TC-250
> URL: https://issues.apache.org/jira/browse/TC-250
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Jeff Elsloo
>Priority: Trivial
>  Labels: crconfig, rpm
>
> The spec file for the Traffic Ops RPM backs up config files and restores them 
> during an upgrade. The the <2.0 versions of Traffic Ops stored the CRConfig 
> config on disk, while it's in the database in >=2.0. This should be removed 
> from the 2.x spec file.
> {code}
> traffic_ops/build/traffic_ops.spec: cd %{PACKAGEDIR} && tar cf 
> /var/tmp/traffic_ops-backup.tar app/public/*Snapshots app/public/routing  
> app/conf app/db/dbconf.yml app/local app/cpanfile.snapshot
> {code}
> Specifically, the {{app/public/*Snapshots}} path likely will not exist. There 
> might be {{Trafficserver-Snapshots}} but definitely not CRConfig.



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

[jira] [Updated] (TC-252) Child server updates - Enhance POST /api/$version/servers/:id/queue_update to queue child servers only

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-252:
---
Labels: api_servers cache_updates  (was: cache_updates)

>  Child server updates - Enhance POST /api/$version/servers/:id/queue_update 
> to queue child servers only
> ---
>
> Key: TC-252
> URL: https://issues.apache.org/jira/browse/TC-252
> 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: api_servers, cache_updates
>
> Provide the ability to queue updates on a cache's children caches (aka the 
> caches that belong to that cache's child cache groups.)
> This is needed when a cache is set to admin down and all the child caches 
> will need to fetch updates to get the change to parent.config (which will 
> exclude the parent cache).
> The support of a request property like { "childrenOnly":true } would suffice. 
> So you'd have a call like this:
> POST /api/$version/servers/:id/queue_update { "action": "queue", 
> "childrenOnly": true }
> to queue the updates of the children caches only (not the parent cache).



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

[jira] [Updated] (TC-260) TO crash on missing regex on creating delivery service in UI

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-260:
---
Labels: host_regex  (was: )

> TO crash on missing regex on creating delivery service in UI
> 
>
> Key: TC-260
> URL: https://issues.apache.org/jira/browse/TC-260
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
> Environment: development
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
>  Labels: host_regex
> Fix For: 2.1.0
>
>
> tried creating a delivery service,  but forgot to put in a regex.   Looks 
> like it tried to give an error message popup, but showed this fatal error and 
> stack trace instead:
>Traffic Ops fatal error occurred while processing your request.
>Error at line 28 ($morbo->run($app);)
>Please supply a host regular expression at 
>.../app/local/lib/perl5/Mojolicious/Controller.pm line 37  
>Mojolicious::Controller::AUTOLOAD('UI::DeliveryService=HASH(0x7e4fd78)', 
>'HOST_REGEXP', '', 'cdn1.kabletown.net', 1, undef)
> called at.../app/lib/UI/DeliveryService.pm line 394 
>   
>  
> UI::DeliveryService::check_deliveryservice_input('UI::DeliveryService=HASH(0x7e4fd78)',
>  1)
> called at.../app/lib/UI/DeliveryService.pm line 1020 
>UI::DeliveryService::create('UI::DeliveryService=HASH(0x7e4fd78)')
> called at.../app/local/lib/perl5/Mojolicious.pm line 126 
>Mojolicious::__ANON__(undef, 'UI::DeliveryService=HASH(0x7e4fd78)', 
>'CODE(0x688fd18)', 1)
> called at.../app/local/lib/perl5/Mojolicious/Plugins.pm line 20 
>Mojolicious::Plugins::__ANON__()
> called at.../app/local/lib/perl5/Mojolicious/Plugins.pm line 23 
> Mojolicious::Plugins::emit_chain('Mojolicious::Plugins=HASH(0x23d68a8)', 
> 'around_action', 'UI::DeliveryService=HASH(0x7e4fd78)', 'CODE(0x688fd18)', 1)
>  called at.../app/local/lib/perl5/Mojolicious/Routes.pm line 106 
> Mojolicious::Routes::_action('TrafficOps=HASH(0x2a09d78)', 
> 'UI::DeliveryService=HASH(0x7e4fd78)', 'CODE(0x688fd18)', 1)



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

[jira] [Updated] (TC-261) Add ability to configure steering subordinates with 0 weight

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-261:
---
Labels: configuration steering  (was: )

> Add ability to configure steering subordinates with 0 weight
> 
>
> Key: TC-261
> URL: https://issues.apache.org/jira/browse/TC-261
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Ops API, Traffic Router
>Reporter: Jeff Elsloo
>Assignee: Jeff Elsloo
>Priority: Minor
>  Labels: configuration, steering
> Fix For: 2.1.0
>
>
> Add the ability to use a 0 weight with steering delivery service 
> subordinates, and optionally include the ability to specify an order. We'll 
> need to enhance the TO UI, API and TR.



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

[jira] [Updated] (TC-263) deliveryservices fetching by type returns internal server error

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-263:
---
 Labels: api_deliveryservices  (was: )
Summary: deliveryservices fetching by type returns internal server error  
(was: TO API - fetching deliveryservices by type returns internal server error)

> deliveryservices fetching by type returns internal server error
> ---
>
> Key: TC-263
> URL: https://issues.apache.org/jira/browse/TC-263
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>  Labels: api_deliveryservices
> Fix For: 2.1.0
>
>
> GET /api/version/deliveryservices?type=typeId returns internal server error. 
> [2017-05-01 10:39:10,604] [ERROR] DBIx::Class::Storage::DBI::_dbh_execute(): 
> DBI Exception: DBD::Pg::st execute failed: ERROR:  column reference "type" is 
> ambiguous



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

[jira] [Updated] (TC-266) Profiles filter profiles by type functionality

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-266:
---
Labels: profile_type_values profiles  (was: )

> Profiles filter profiles by type functionality
> --
>
> Key: TC-266
> URL: https://issues.apache.org/jira/browse/TC-266
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: profile_type_values, profiles
> Fix For: 2.1.0
>
>
> Add a query parameter to GET /api/version/profiles to filter profiles by 
> type. 
> i.e.
> GET /api/version/profiles?type=DS_PROFILE
> valid profile types can be found in profile_type_values



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

[jira] [Updated] (TC-269) Change log filter by user functionality

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-269:
---
Labels: change_log logs  (was: )

> Change log filter by user functionality
> ---
>
> Key: TC-269
> URL: https://issues.apache.org/jira/browse/TC-269
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: change_log, logs
>
> add support for a user query param on the GET /api/version/logs to filter the 
> logs by a user.
> GET /api/version/logs?user=tbone345



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

[jira] [Updated] (TC-269) Change log filter by user functionality

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-269:
---
Summary: Change log filter by user functionality  (was: TO API - provide 
the ability to filter change logs by user)

> Change log filter by user functionality
> ---
>
> Key: TC-269
> URL: https://issues.apache.org/jira/browse/TC-269
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: change_log, logs
>
> add support for a user query param on the GET /api/version/logs to filter the 
> logs by a user.
> GET /api/version/logs?user=tbone345



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

[jira] [Updated] (TC-274) cache_stats and deliveryservice_stats endpoints should use configurable retention period value

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-274:
---
 Labels: cache_stats deliveryservice_stats logs retention  (was: )
Summary: cache_stats and deliveryservice_stats endpoints should use 
configurable retention period value  (was: TO API: cache_stats and 
deliveryservice_stats endpoints should use configurable retention period value)

> cache_stats and deliveryservice_stats endpoints should use configurable 
> retention period value
> --
>
> Key: TC-274
> URL: https://issues.apache.org/jira/browse/TC-274
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Priority: Minor
>  Labels: cache_stats, deliveryservice_stats, logs, retention
>
> The implementation of the following APIs use hard-coded values for the 
> Retention Period
> GET api/version/cache_stats
> GET api/version/deliveryservice_stats
> notice the "monthly" in the queries:
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/Builder/CacheStatsBuilder.pm#L78
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/Builder/CacheStatsBuilder.pm#L95
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/Builder/DeliveryServiceStatsBuilder.pm#L81
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/Builder/DeliveryServiceStatsBuilder.pm#L96
> this retention period name should be configurable and probably stored in the 
> influxdb.conf files.



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

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

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-275:
---
Summary: Export/Import delivery service  (was: Traffic Ops - Export/Import 
delivery service)

> 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
>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] [Updated] (TC-282) error updating server

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-282:
---
Labels: configuration validation  (was: )

> error updating server
> -
>
> Key: TC-282
> URL: https://issues.apache.org/jira/browse/TC-282
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>  Labels: configuration, validation
> Fix For: 2.1.0
>
>
> updating a server in the UI with new IP address info.On SAVE,   I get 
> this error:
> ```
> Traffic Ops fatal error occurred while processing your request. 
> Error at line 452 (   if ( $profile->cdn->id != $cdn->id ) {) 
> Can't call method "id" on an undefined value at 
> /opt/traffic_ops/app/lib/UI/Server.pm line 452.
> ```



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

[jira] [Updated] (TC-283) traffic ops api (PUT api/.../server/...) doc inconsistent with code

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-283:
---
Labels: api_server  (was: )

> traffic ops api (PUT api/.../server/...) doc inconsistent with code
> ---
>
> Key: TC-283
> URL: https://issues.apache.org/jira/browse/TC-283
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>  Labels: api_server
>
> The Traffic Ops API documentation for "PUT /api/1.2/servers/{:id}" shows that 
> "type" is a required field.   It's actually "type_id".  I think that's true 
> for all the fields representing foreign keys.
> Documentation is here: 
> http://trafficcontrol.incubator.apache.org/docs/latest/development/traffic_ops_api/v12/server.html
> Code is here: 
> https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Server.pm#L201



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

[jira] [Updated] (TC-285) When deleting delivery services associated parameters should be deleted

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-285:
---
Labels: configuration parameters validation  (was: )

> When deleting delivery services associated parameters should be deleted
> ---
>
> Key: TC-285
> URL: https://issues.apache.org/jira/browse/TC-285
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Derek Gelinas
>  Labels: configuration, parameters, validation
>
> All associated parameters like certificates, plugins, and delivery service 
> profiles should be deleted.



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

[jira] [Updated] (TC-287) Add support for per-Delivery Service routing/name

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-287:
---
Labels: crconfig routing  (was: )

> Add support for per-Delivery Service routing/name
> -
>
> Key: TC-287
> URL: https://issues.apache.org/jira/browse/TC-287
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Router
>Reporter: Eric Friedrich
>Assignee: Rawlin Peters
>  Labels: crconfig, routing
>
> A default routing name/entry point should be added as a profile parameter, 
> and this parameter should be used by default as the value of the "routing 
> name" or "entry point" on the delivery service in the CRConfig. This value 
> should be overridable on a per-delivery service level, which means that the 
> delivery service UIs should be enhanced to provide this capability and to 
> display the default value.
> Once above is implemented, consume the new delivery service parameter and 
> configure accordingly within Traffic Router.
> From: 
> https://github.com/Comcast/traffic_control/issues/61
> https://github.com/Comcast/traffic_control/issues/62



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

[jira] [Updated] (TC-292) Traffic Ops. Warn when a delivery service is not assigned

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-292:
---
Labels: assignment configuration validation  (was: )

> Traffic Ops. Warn when a delivery service is not assigned
> -
>
> Key: TC-292
> URL: https://issues.apache.org/jira/browse/TC-292
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Eric Friedrich
>Priority: Trivial
>  Labels: assignment, configuration, validation
>
> When pushing close on the delivery service screen a box should pop up when 
> there have been no server assignments for the delivery service. This should 
> only occur if the delivery service has been set to active.
> https://github.com/Comcast/traffic_control/issues/197



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

[jira] [Updated] (TC-302) Change Log Created On Edit Profile Details and Close - GH #1341

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-302:
---
Labels: configuration logs  (was: Configuration Logging)

> Change Log Created On Edit Profile Details and Close - GH #1341
> ---
>
> Key: TC-302
> URL: https://issues.apache.org/jira/browse/TC-302
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Dewayne Richardson
>  Labels: configuration, logs
>
> I was seeing some Change Log entries which made me question my team mates.
> Update profile with name: EDGE_R730XD_532-733
> They haven't changed anything, but here's the steps to reproduce.
> Parameters -> Select Profile
> Select Profile Details
> Select Edit
> Select Close (So no change are done, they simply wanted to copy)
> At this point, a change log entry is produced for something that wasn't 
> updated.
> https://github.com/Comcast/traffic_control/blob/master/traffic_ops/app/lib/UI/Profile.pm#L190-L212



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

[jira] [Issue Comment Deleted] (TC-303) Influx summary query returns results not found in the corresponding series query (i.e. max and min)

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-303:
---
Comment: was deleted

(was: Should influx.db be its own component?)

> Influx summary query returns results not found in the corresponding series 
> query (i.e. max and min) 
> 
>
> Key: TC-303
> URL: https://issues.apache.org/jira/browse/TC-303
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>Priority: Minor
>  Labels: influx
>
> From https://github.com/Comcast/traffic_control/issues/539
> For example, the influx series query results may look like this:
> [
> [time, value],
> [time, 10],
> [time, 20],
> [time, 34],
> [time, 26]
> ]
> and the influx summary query results for the same timeframe may look like:
> {
> time: x,
> mean: y,
> min: 8,
> max: 75
> }
> notice how the min=8 and max=75 is strange because 8 and 75 are not found in 
> the series query. this is because the series query is being grouped into 60s 
> intervals (which is an average of 6 10s intervals) but the summary query 
> looks at every value recorded in influx (on the 10s interval) between the 
> timeframe.
> so in this example, i would expect min=10 and max=34
> maybe it's possible to run the summary query against the series query 
> results?? like a subselect query like this:
> SELECT mean(value), percentile(value, 5), percentile(value, 95), 
> percentile(value, 98), min(value), max(value), count(value) FROM (SELECT 
> sum(value)/count(value) FROM tps_total WHERE cachegroup = 'total' AND 
> deliveryservice = 'ds-name' AND time >='2015-09-17T03:38:00-06:00' AND time 
> <= '2015-09-17T15:38:00-06:00' GROUP BY time(60s), cachegroup)
> this bug pertains to the following api endpoint 
> /api/version/deliveryservice_stats.json when data source is influx.
> here are a couple sample influx queries:
> summary_query #-> $VAR1 = 'SELECT mean(value), percentile(value, 5), 
> percentile(value, 95), percentile(value, 98), min(value), max(value), 
> count(value) FROM tps_total WHERE time >= '2015-09-17T03:38:00-06:00' AND 
> time <= '2015-09-17T15:38:00-06:00' AND cachegroup = 'total' AND 
> deliveryservice = 'ds-name'';
> series_query #-> $VAR1 = 'SELECT sum(value)/count(value) FROM tps_total WHERE 
> cachegroup = 'total' AND deliveryservice = 'ds-name' AND time 
> >='2015-09-17T03:38:00-06:00' AND time <= '2015-09-17T15:38:00-06:00' GROUP 
> BY time(60s), cachegroup';
> from [~mitchell...@apache.org]:
> this is not fixed. :( if you pass in another interval like 1h, this issue 
> again occurs.
> this will require a summary query based on a series query or basically a 
> nested query as the issue suggested and nested queries are not yet supported 
> in influxdb - influxdb/influxdb#52



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

[jira] [Updated] (TC-303) Influx summary query returns results not found in the corresponding series query (i.e. max and min)

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-303:
---
Labels: influx  (was: )

> Influx summary query returns results not found in the corresponding series 
> query (i.e. max and min) 
> 
>
> Key: TC-303
> URL: https://issues.apache.org/jira/browse/TC-303
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>Priority: Minor
>  Labels: influx
>
> From https://github.com/Comcast/traffic_control/issues/539
> For example, the influx series query results may look like this:
> [
> [time, value],
> [time, 10],
> [time, 20],
> [time, 34],
> [time, 26]
> ]
> and the influx summary query results for the same timeframe may look like:
> {
> time: x,
> mean: y,
> min: 8,
> max: 75
> }
> notice how the min=8 and max=75 is strange because 8 and 75 are not found in 
> the series query. this is because the series query is being grouped into 60s 
> intervals (which is an average of 6 10s intervals) but the summary query 
> looks at every value recorded in influx (on the 10s interval) between the 
> timeframe.
> so in this example, i would expect min=10 and max=34
> maybe it's possible to run the summary query against the series query 
> results?? like a subselect query like this:
> SELECT mean(value), percentile(value, 5), percentile(value, 95), 
> percentile(value, 98), min(value), max(value), count(value) FROM (SELECT 
> sum(value)/count(value) FROM tps_total WHERE cachegroup = 'total' AND 
> deliveryservice = 'ds-name' AND time >='2015-09-17T03:38:00-06:00' AND time 
> <= '2015-09-17T15:38:00-06:00' GROUP BY time(60s), cachegroup)
> this bug pertains to the following api endpoint 
> /api/version/deliveryservice_stats.json when data source is influx.
> here are a couple sample influx queries:
> summary_query #-> $VAR1 = 'SELECT mean(value), percentile(value, 5), 
> percentile(value, 95), percentile(value, 98), min(value), max(value), 
> count(value) FROM tps_total WHERE time >= '2015-09-17T03:38:00-06:00' AND 
> time <= '2015-09-17T15:38:00-06:00' AND cachegroup = 'total' AND 
> deliveryservice = 'ds-name'';
> series_query #-> $VAR1 = 'SELECT sum(value)/count(value) FROM tps_total WHERE 
> cachegroup = 'total' AND deliveryservice = 'ds-name' AND time 
> >='2015-09-17T03:38:00-06:00' AND time <= '2015-09-17T15:38:00-06:00' GROUP 
> BY time(60s), cachegroup';
> from [~mitchell...@apache.org]:
> this is not fixed. :( if you pass in another interval like 1h, this issue 
> again occurs.
> this will require a summary query based on a series query or basically a 
> nested query as the issue suggested and nested queries are not yet supported 
> in influxdb - influxdb/influxdb#52



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

[jira] [Created] (TC-389) pkg build script should be more helpful

[Dan Kirkwood (JIRA)]

Dan Kirkwood created TC-389:
---

 Summary: pkg build script should be more helpful
 Key: TC-389
 URL: https://issues.apache.org/jira/browse/TC-389
 Project: Traffic Control
  Issue Type: Improvement
Reporter: Dan Kirkwood


Tried out the ./pkg build script with docker and docker-compose properly 
installed.

It failed, but gave me no information whatsoever.  Also,  no dist directory,  
so no log files from docker-compose:

{code}
$ ./pkg source traffic_ops_build
Building source.
Building traffic_ops_build.
Failed to build source traffic_ops_build.
{code}



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

[jira] [Updated] (TC-305) Deleting a delivery service does not delete SSL keys from Traffic Vault

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-305:
---
 Labels: configuration keys ssl validation  (was: )
Description: 

https://github.com/Comcast/traffic_control/issues/1325

  was:


https://github.com/Comcast/traffic_control/issues/1325

Component/s: Traffic Ops API

> Deleting a delivery service does not delete SSL keys from Traffic Vault
> ---
>
> Key: TC-305
> URL: https://issues.apache.org/jira/browse/TC-305
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Eric Friedrich
>Priority: Minor
>  Labels: configuration, keys, ssl, validation
>
> https://github.com/Comcast/traffic_control/issues/1325



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

[jira] [Updated] (TC-309) No Cache-Control on images

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-309:
---
Labels: cache-control  (was: )

> No Cache-Control on images
> --
>
> Key: TC-309
> URL: https://issues.apache.org/jira/browse/TC-309
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Steve Malenfant
>Priority: Trivial
>  Labels: cache-control
>
> From GH issue #962:
> This was observed during 1.3.0RC6 testing. The headers are different in 1.1.6 
> (actually not cache-control headers).
> Images didn't show up sometimes, high latency to display the Health->Table 
> View.
> Is this a byproduct of using localhost connection (through Vagrant) ?
> But doesn't seems like this code changed along the way...
> {code}
> Request URL:https://127.0.0.1:4443/images/graph.png
> Request Method:GET
> Status Code:200 OK
> Remote Address:127.0.0.1:4443
> Response Headers
> view source
> Accept-Ranges:bytes
> Access-Control-Allow-Credentials:true
> Access-Control-Allow-Headers:Origin, X-Requested-With, Content-Type, Accept
> Access-Control-Allow-Methods:POST,GET,OPTIONS,PUT,DELETE
> Access-Control-Allow-Origin:http://localhost:8080
> Cache-Control:no-cache, no-store, max-age=0, must-revalidate
> Connection:keep-alive
> Content-Length:892
> Content-Type:image/png
> Date:Fri, 22 Jan 2016 15:03:36 GMT
> Last-Modified:Fri, 22 Jan 2016 13:14:28 GMT
> Server:Mojolicious (Perl)
> {code}
> Logs
> {code}
> 10.0.2.2 - - [22/Jan/2016:15:11:55 +] "GET 
> /api/1.1/traffic_monitor/stats.json?data_type=json HTTP/1.1" 200 73
> 10.0.2.2 - - [22/Jan/2016:15:11:55 +] "GET /images/good.png HTTP/1.1" 200 
> 617
> 10.0.2.2 - - [22/Jan/2016:15:11:55 +] "GET /images/graph.png HTTP/1.1" 
> 200 892
> 10.0.2.2 - - [22/Jan/2016:15:12:00 +] "GET 
> /api/1.1/traffic_monitor/stats.json?data_type=json HTTP/1.1" 200 73
> 10.0.2.2 - - [22/Jan/2016:15:12:02 +] "GET 
> /api/1.1/traffic_monitor/stats.json?data_type=json HTTP/1.1" 200 73
> 10.0.2.2 - - [22/Jan/2016:15:12:02 +] "GET /images/good.png HTTP/1.1" 200 
> 617
> 10.0.2.2 - - [22/Jan/2016:15:12:02 +] "GET /images/graph.png HTTP/1.1" 
> 200 892
> {code}
> By default, the cdn.conf contains an entry showing
> {code}
>   cors => {
> access_control_allow_origin => 'http://localhost:8080'
>   },
> {code}
> Comment those lines and this will disable the Cache-Control headers for all 
> files. Use only if you are not going through a proxy. Enjoy the fast UI again.
> The Cache Control should be changed for static files. These should probably 
> be set to something like max-age=86400. When doing development, these should 
> be disabled so one doesn't get frustrated not seeing updates made...
> {code}
> /opt/traffic_ops/app/public/css
> /opt/traffic_ops/app/public/images
> /opt/traffic_ops/app/public/js
> /opt/traffic_ops/app/public/theme
> {code}



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

[jira] [Updated] (TC-313) Inconsistent edge parent.config configuration using secondary parent

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-313:
---
 Labels: parent.config  (was: )
Summary: Inconsistent edge parent.config configuration using secondary 
parent  (was: TO: Inconsistent edge parent.config configuration using secondary 
parent)

> Inconsistent edge parent.config configuration using secondary parent
> 
>
> Key: TC-313
> URL: https://issues.apache.org/jira/browse/TC-313
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 1.8.0, 2.0.0
>Reporter: Matt Mills
>Priority: Minor
>  Labels: parent.config
>
> Original issue: https://github.com/Comcast/traffic_control/issues/1349
> I have the following configuration in Traffic Ops :
> | cache-group | primary parent | secondary parent |
> | --- | --- | --- |
> | vm-cdn1-east-edge | vm-cdn1-east-mid | vm-cdn1-west-mid |
> | vm-cdn1-west-edge | vm-cdn1-west-mid | vm-cdn1-east-mid |
> Edge configuration is inconsistent from both a parent/secondary perspective 
> and IP/names.
> - `dest_domain=origin.services.coxlab.net` has the proper parents and using 
> IPs.
> - `dest_domain=.` has all the parent in the same exact group. Also, it is 
> using DNS names instead of IPs. This seems to be there since the beginning.
> - I feel like I'm missing a parameter, but this configuration here doesn't 
> look consistent.
> {code}
> dest_domain=origin.services.coxlab.net 
> parent="68.1.14.137:80|0.999;68.1.14.138:80|0.999;68.1.14.152:80|0.999;" 
> secondary_parent="68.1.14.153:80|0.999;68.1.14.154:80|0.999;68.1.14.155:80|0.999;"
>  round_robin=consistent_hash go_direct=false qstring=ignore
> dest_domain=. 
> parent="cdn1cdmid0001.coxlab.net:80|0.999;cdn1cdmid0002.coxlab.net:80|0.999;cdn1cdmid0003.coxlab.net:80|0.999;cdn1cdmid0004.coxlab.net:80|0.999;cdn1cdmid0005.coxlab.net:80|0.999;cdn1cdmid0006.coxlab.net:80|0.999;"
>  round_robin=consistent_hash go_direct=false qstring=ignore
> {code}



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

[jira] [Updated] (TC-317) ORT syncds bug - Parent holds up child running syncds if TO has multiple CDNs

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-317:
---
Labels: syncds  (was: Configuration)

> ORT syncds bug - Parent holds up child running syncds if TO has multiple CDNs
> -
>
> Key: TC-317
> URL: https://issues.apache.org/jira/browse/TC-317
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops ORT
>Reporter: Nir Sopher
>  Labels: syncds
>
> Based on: https://github.com/Comcast/traffic_control/issues/1380
> By: jpappa200
> A parent from a different CDN can hold up a child from running syncds if 
> Traffic Ops has multiple CDN's configured.
> https:///update/ looks at all parents associated with the cache 
> group and doesn't check which CDN it's associated with.
> Comment by jeffmart:
> Is this hold up indefinite?
> or
> does syncds complete on the child after all parents for all CDNs in that 
> cache group are updated?
> I am assuming https://github.com/Comcast/traffic_control/pull/2 but want to 
> make sure
> knutsel :
> so we have a issue somewhere to take regex_revalidate out of the ort/syncds 
> distribution mechanism, and scp (or ansible dist) it directly on update; this 
> would remove the "mids have to complete ort syncds before edges" requirement, 
> and things should get a lot better when we do that...



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

[jira] [Updated] (TC-318) Chart creation for non-cache servers such as Traffic Routers, Traffic Monitors, Influxdb

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-318:
---
 Labels: chart log_aggregation  (was: )
Component/s: Traffic Portal
Summary: Chart creation for non-cache servers such as Traffic Routers, 
Traffic Monitors, Influxdb   (was: graph link on server page for non-cache 
servers)

> Chart creation for non-cache servers such as Traffic Routers, Traffic 
> Monitors, Influxdb 
> -
>
> Key: TC-318
> URL: https://issues.apache.org/jira/browse/TC-318
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Portal
>Reporter: Derek Gelinas
>  Labels: chart, log_aggregation
>
> copied from https://github.com/Comcast/traffic_control/issues/1736
> On the servers page in TO there is a graph icon which leads to graphs for 
> caches. This icon is currently not present for other types of servers such as 
> Traffic Routers, Traffic Monitors, Influxdb servers, etc. We should create 
> some scripted dashboards and update Traffic Ops so that all server types have 
> graphs with at least grafana data.



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

[jira] [Updated] (TC-320) cache url config parameters not created at the Mid Caches

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-320:
---
Labels: cache_url configuration  (was: Configuration)

> cache url config parameters not created at the Mid Caches
> -
>
> Key: TC-320
> URL: https://issues.apache.org/jira/browse/TC-320
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Steve Malenfant
>Priority: Minor
>  Labels: cache_url, configuration
>
> From GH issue 1743:
> We created a new delivery service and used the Cache URL expression. The 
> parameters got created for Edges, but not for the Mids. Thus making ORT and 
> ATS complain.



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

[jira] [Updated] (TC-323) urlkeys endpoint returning a HASH

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-323:
---
 Labels: urlkeys  (was: )
Component/s: Traffic Ops API
Summary: urlkeys endpoint returning a HASH  (was: TO API: urlkeys 
endpoint returning a HASH)

> urlkeys endpoint returning a HASH
> -
>
> Key: TC-323
> URL: https://issues.apache.org/jira/browse/TC-323
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Eric Friedrich
>Priority: Minor
>  Labels: urlkeys
>
> I was trying to automate url key extractions from TO, although looks like 
> this API doesn't return the content I was expecting. This might not be a 
> documented API either.
> https://to.kabletown.net/api/1.2/deliveryservices/xmlId/test_ds/urlkeys.json
> {"response":"HTTP::Response=HASH(0x7ecc440)"}
> https://github.com/Comcast/traffic_control/issues/1529



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

[jira] [Updated] (TC-324) Import profile should check if delivery service that is referenced is present in the traffic ops that is being imported to.

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-324:
---
Labels: configuration profile validation  (was: Configuration)

> Import profile should check if delivery service that is referenced is present 
> in the traffic ops that is being imported to.
> ---
>
> Key: TC-324
> URL: https://issues.apache.org/jira/browse/TC-324
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Eric Friedrich
>Priority: Minor
>  Labels: configuration, profile, validation
>
> There are some parameters possible in a profile that are associated with a 
> delivery service, for example the location parameter for the regex_remap, 
> header_rewrite remap lines... These should be dropped if there is no matching 
> delivery service on the system where you import to?



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

[jira] [Updated] (TC-325) Traffic Ops Client documentation

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-325:
---
 Labels: documentation  (was: )
Component/s: Traffic Portal
 Traffic Ops
 Documentation

> Traffic Ops Client documentation
> 
>
> Key: TC-325
> URL: https://issues.apache.org/jira/browse/TC-325
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Documentation, Traffic Ops, Traffic Ops Client , Traffic 
> Portal
>Reporter: Nir Sopher
>Priority: Minor
>  Labels: documentation
>
> Based on: https://github.com/Comcast/traffic_control/issues/1808
> By dneuman64:
> There is currently little to no documentation available for the traffic ops 
> client. The client should be documented so that a user can quickly get up and 
> running with it.



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

[jira] [Commented] (TC-325) Traffic Ops Client documentation

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-325:


Does this requirement go away as we transition to a single traffic portal, 
assuming the traffic portal is well documented?

> Traffic Ops Client documentation
> 
>
> Key: TC-325
> URL: https://issues.apache.org/jira/browse/TC-325
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops Client 
>Reporter: Nir Sopher
>Priority: Minor
>
> Based on: https://github.com/Comcast/traffic_control/issues/1808
> By dneuman64:
> There is currently little to no documentation available for the traffic ops 
> client. The client should be documented so that a user can quickly get up and 
> running with it.



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

[jira] [Updated] (TC-327) ConfigFiles.pm detects blank as not null and tries to gen files GH #1090

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-327:
---
Labels: configfiles.pm configuration  (was: Configuration)

> ConfigFiles.pm detects blank as not null and tries to gen files GH #1090
> 
>
> Key: TC-327
> URL: https://issues.apache.org/jira/browse/TC-327
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Dewayne Richardson
>Assignee: Derek Gelinas
>  Labels: configfiles.pm, configuration
>
> ConfigFiles.pm will read a blank in the database as a file that needs 
> creation or action upon. Some defensive code should detect this issue and 
> either treat it as a null or pitch an error with some troubleshooting steps 
> to fix the issue.



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

[jira] [Updated] (TC-331) LDAP search filter contains Active Directory specific attributes

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-331:
---
Labels: active_directory ldap  (was: )

> LDAP search filter contains Active Directory specific attributes
> 
>
> Key: TC-331
> URL: https://issues.apache.org/jira/browse/TC-331
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Reporter: Jeff Elsloo
>Priority: Minor
>  Labels: active_directory, ldap
>
> Moved from https://github.com/Comcast/traffic_control/issues/1129
> The search filter used to locate user DNs contains hard coded values that 
> only work with Active Directory:
> $mesg = $ldap->search( base => $search_base, filter => 
> "(&(objectCategory=person)(objectClass=user)(sAMAccountName=$username))" );
> This search filter should be configurable and should be in ldap.conf. 
> Instead, it's hard coded in TrafficOps.pm.
> For example, this search filter would work with most non-AD based LDAP severs:
> (&(objectClass=inetOrgPerson)(uid=$username))



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

[jira] [Updated] (TC-332) Heatlh tab never loads if there are no traffic monitors

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-332:
---
 Labels: health  (was: )
Component/s: Traffic Portal

> Heatlh tab never loads if there are no traffic monitors
> ---
>
> Key: TC-332
> URL: https://issues.apache.org/jira/browse/TC-332
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Portal
>Reporter: Nir Sopher
>Priority: Minor
>  Labels: health
>
> Based on: 
> https://github.com/Comcast/traffic_control/issues/494
> by petrocc:
> If there are no traffic monitors the health tab sits at "loading...". This is 
> probably not desired behavior.



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

[jira] [Updated] (TC-333) Mid Header Rewrite needs to be added to remap.config

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-333:
---
Labels: header_rewrite  (was: )

> Mid Header Rewrite needs to be added to remap.config
> 
>
> Key: TC-333
> URL: https://issues.apache.org/jira/browse/TC-333
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Steve Malenfant
>Assignee: Jan van Doorn
>Priority: Minor
>  Labels: header_rewrite
>
> Due to a mis-behaving origin, I want to override the Cache-Control (there 
> isn't any in my case) using "Mid Header Rewrite". The delivery service 
> feature does write the proper file to disk, but there is no remap rule set 
> (basically doesn't do anything).
> The following map needs to be added when used:
> map http://originfqdn http://originfqdn @plugin=header_rewrite.so 
> @pparam=hdr_rw_mid_.config
> Note: Missing header rewrite in the profile table is the root cause. Need to 
> make sure they are added.



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

[jira] [Commented] (TC-333) Mid Header Rewrite needs to be added to remap.config

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-333:


Has this been resolved?  I know we are currently able to rewrite the headers at 
the mid tier through mid header rewrite rule.  Or, am I missing something?

> Mid Header Rewrite needs to be added to remap.config
> 
>
> Key: TC-333
> URL: https://issues.apache.org/jira/browse/TC-333
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Steve Malenfant
>Assignee: Jan van Doorn
>Priority: Minor
>
> Due to a mis-behaving origin, I want to override the Cache-Control (there 
> isn't any in my case) using "Mid Header Rewrite". The delivery service 
> feature does write the proper file to disk, but there is no remap rule set 
> (basically doesn't do anything).
> The following map needs to be added when used:
> map http://originfqdn http://originfqdn @plugin=header_rewrite.so 
> @pparam=hdr_rw_mid_.config
> Note: Missing header rewrite in the profile table is the root cause. Need to 
> make sure they are added.



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

[jira] [Assigned] (TC-287) Add support for per-Delivery Service routing/name

[Rawlin Peters (JIRA)]

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

Rawlin Peters reassigned TC-287:


Assignee: Rawlin Peters

> Add support for per-Delivery Service routing/name
> -
>
> Key: TC-287
> URL: https://issues.apache.org/jira/browse/TC-287
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Router
>Reporter: Eric Friedrich
>Assignee: Rawlin Peters
>
> A default routing name/entry point should be added as a profile parameter, 
> and this parameter should be used by default as the value of the "routing 
> name" or "entry point" on the delivery service in the CRConfig. This value 
> should be overridable on a per-delivery service level, which means that the 
> delivery service UIs should be enhanced to provide this capability and to 
> display the default value.
> Once above is implemented, consume the new delivery service parameter and 
> configure accordingly within Traffic Router.
> From: 
> https://github.com/Comcast/traffic_control/issues/61
> https://github.com/Comcast/traffic_control/issues/62



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

[jira] [Updated] (TC-334) Allow multiple bypass ip addresses

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-334:
---
Labels: bypass routing  (was: )

> Allow multiple bypass ip addresses
> --
>
> Key: TC-334
> URL: https://issues.apache.org/jira/browse/TC-334
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Router
>Reporter: Jeff Elsloo
>Priority: Trivial
>  Labels: bypass, routing
>
> From GH issue 1579:
> I think this is good practice to allow people to define multiple ip bypass 
> addresses.



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

[jira] [Updated] (TC-336) Add ability to copy url_sig keys from one DS to another GH #1540

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-336:
---
 Labels: keys url_signing  (was: )
Component/s: Traffic Vault

> 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
>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] [Commented] (TC-346) 2.1 (master) Traffic Ops Installation issues.

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-346:


Can this be resolved or 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] [Updated] (TC-346) 2.1 (master) Traffic Ops Installation issues.

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-346:
---
Labels: installation  (was: )

> 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 = 
> 'https://cdn1.denver-isp.org/routing/GeoLiteCityv6.dat.gz') )
> ON CONFLICT 

[jira] [Updated] (TC-350) Traffic Ops Environment needs to be consistent PERL5LIB, GOPATH, and PATH

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-350:
---
Labels: gopath library path  (was: )

> Traffic Ops Environment needs to be consistent PERL5LIB, GOPATH, and PATH
> -
>
> Key: TC-350
> URL: https://issues.apache.org/jira/browse/TC-350
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>Priority: Minor
>  Labels: gopath, library, path
> Fix For: 2.1.0
>
>
> PERL5LIB: 
> /opt/traffic_ops_extensions/private/lib:/opt/traffic_ops/app/lib:/opt/traffic_ops/app/local/lib/perl5
> GOPATH:
> /opt/traffic_ops/go
> PATH:
> $PATH:/opt/traffic_ops/go/bin:/usr/local/go/bin



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

[jira] [Updated] (TC-351) Generate new SSL keys fails after a while

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-351:
---
Labels: ssl  (was: )

> 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-350) Traffic Ops Environment needs to be consistent PERL5LIB, GOPATH, and PATH

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-350:


Can this be resolved or closed?

> Traffic Ops Environment needs to be consistent PERL5LIB, GOPATH, and PATH
> -
>
> Key: TC-350
> URL: https://issues.apache.org/jira/browse/TC-350
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>Priority: Minor
> Fix For: 2.1.0
>
>
> PERL5LIB: 
> /opt/traffic_ops_extensions/private/lib:/opt/traffic_ops/app/lib:/opt/traffic_ops/app/local/lib/perl5
> GOPATH:
> /opt/traffic_ops/go
> PATH:
> $PATH:/opt/traffic_ops/go/bin:/usr/local/go/bin



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

[jira] [Updated] (TC-353) Can't CNAME hostname with "ccr"

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-353:
---
Labels: cname configuration host_regex  (was: )

> Can't CNAME hostname with "ccr"
> ---
>
> Key: TC-353
> URL: https://issues.apache.org/jira/browse/TC-353
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 1.8.0, 2.0.0, 2.1.0
>Reporter: Steve Malenfant
>Priority: Minor
>  Labels: cname, configuration, host_regex
>
> If you put a HOST_REGEX of "ccr.example.kabletown.net", it will expand to the 
> server hostname like "edge01.example.kabletown.net". This makes the 
> remap.config to have the wrong hostname. This might not affect anything but 
> it should be changed to something unrelated to a specific prefix.
> The code ConfigFile.pm is causing the current behavior :
> {code}
>   my $hname = $ds_type =~ /^DNS/ ? "edge" : "ccr";
>   my $portstr = "";
> ...
>   $map_from =~ s/ccr/$host_name/;
> {code}



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

[jira] [Updated] (TC-355) Checks needed to prevent profiles and servers having different CDNs assigned

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-355:
---
Labels: configuration profiles validation  (was: configuration_validation)

> Checks needed to prevent profiles and servers having different CDNs assigned
> 
>
> Key: TC-355
> URL: https://issues.apache.org/jira/browse/TC-355
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.0.0
>Reporter: Derek Gelinas
>Assignee: Derek Gelinas
>  Labels: configuration, profiles, validation
> Fix For: 2.1.0
>
>
> It should not be possible to assign servers to a profile with a different or 
> null CDN value.  It should also not be possible to change a profile's CDN 
> when there are servers assigned to that profile on a different CDN.



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

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

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-364:
---
Labels: assignment delivery_service user  (was: )

> 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
>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] [Updated] (TC-368) /api/1.2/deliveryservices/:id/routing.json hangs when Traffic Router is unreachable

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-368:
---
Labels: routing  (was: )

> /api/1.2/deliveryservices/:id/routing.json hangs when Traffic Router is 
> unreachable
> ---
>
> Key: TC-368
> URL: https://issues.apache.org/jira/browse/TC-368
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 1.8.0
>Reporter: Steve Malenfant
>  Labels: routing
>
> I was testing this API "/api/1.2/deliveryservices/:id/routing.json" and found 
> that it would hang and the perl worker had to be killled. This caused 500 
> Errors back from TO API.
> The root cause is Traffic Router not responding to API Port. 
> We should not poll Traffic Router that are status=OFFLINE and there should be 
> some sort of timeouts in place to make sure it doesn't take more than x 
> seconds to return information from API
> There is some comments in the code that seems to indication prior issues.
> `# TODO: what happens when the request to CCR times out?`



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

[jira] [Updated] (TC-369) ORT recreates certain files on each run.

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-369:
---
Labels: parent.config  (was: )

> ORT recreates certain files on each run.
> 
>
> Key: TC-369
> URL: https://issues.apache.org/jira/browse/TC-369
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops ORT
>Affects Versions: 2.1.0
>Reporter: Joseph Pappano
>Assignee: Derek Gelinas
>Priority: Minor
>  Labels: parent.config
>
> each time ORT runs there will be subtle differences in parent.config and 
> other files and they are needlessly recreated.



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

[jira] [Updated] (TC-371) Assigning servers to ds thru API takes too long

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-371:
---
Labels: assignment delivery_service server  (was: )

> Assigning servers to ds thru API takes too long
> ---
>
> Key: TC-371
> URL: https://issues.apache.org/jira/browse/TC-371
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>  Labels: assignment, delivery_service, server
>
> POST /api/$version/deliveryserviceserver takes the following payload:
> {  dsId: 42, servers: [1,2,3,4,5,6,7,8,9...] }
> and it loops thru each server to perform a query to see if it exists and then 
> does a query to do an insert into the deliveryservice_server table. so if 
> you're assigning 500 servers to a ds...you end up with 1000 queries... 
> need to optimize this endpoint.



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

[jira] [Commented] (TC-371) Assigning servers to ds thru API takes too long

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-371:


Can this be resolved or closed?


> Assigning servers to ds thru API takes too long
> ---
>
> Key: TC-371
> URL: https://issues.apache.org/jira/browse/TC-371
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>
> POST /api/$version/deliveryserviceserver takes the following payload:
> {  dsId: 42, servers: [1,2,3,4,5,6,7,8,9...] }
> and it loops thru each server to perform a query to see if it exists and then 
> does a query to do an insert into the deliveryservice_server table. so if 
> you're assigning 500 servers to a ds...you end up with 1000 queries... 
> need to optimize this endpoint.



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

[jira] [Commented] (TC-372) Assigning ds's to user thru API takes too long

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-372:


Can this be resolved or closed?

> Assigning ds's to user thru API takes too long
> --
>
> Key: TC-372
> URL: https://issues.apache.org/jira/browse/TC-372
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>  Labels: delivery_service, tenant, user
>
> POST /api/$version/deliveryservice_user takes the following payload:
> { userId: 42, deliveryServices: [1,2,3,4,5,6,7,8,9...] }
> and it loops thru each ds to perform a query to see if it exists and then 
> does a query to do an insert into the deliveryservice_tmuser table. so if 
> you're assigning 500 ds's to a user...you end up with 1000 queries...
> need to optimize this endpoint.



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

[jira] [Updated] (TC-372) Assigning ds's to user thru API takes too long

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-372:
---
 Labels: delivery_service tenant user  (was: )
Component/s: Traffic Ops

> Assigning ds's to user thru API takes too long
> --
>
> Key: TC-372
> URL: https://issues.apache.org/jira/browse/TC-372
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>  Labels: delivery_service, tenant, user
>
> POST /api/$version/deliveryservice_user takes the following payload:
> { userId: 42, deliveryServices: [1,2,3,4,5,6,7,8,9...] }
> and it loops thru each ds to perform a query to see if it exists and then 
> does a query to do an insert into the deliveryservice_tmuser table. so if 
> you're assigning 500 ds's to a user...you end up with 1000 queries...
> need to optimize this endpoint.



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

[jira] [Updated] (TC-374) `systemctl stop traffic_ops` does not kill all processes

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-374:
---
Labels: systemctl  (was: )

> `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] [Updated] (TC-375) yum upgrade traffic_ops... can't find goose

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-375:
---
Labels: goose postinstall yum  (was: )

> yum upgrade traffic_ops... can't find goose
> ---
>
> Key: TC-375
> URL: https://issues.apache.org/jira/browse/TC-375
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>  Labels: goose, postinstall, yum
> Fix For: 2.1.0
>
>
> Traffic Ops postinstall puts goose in /opt/traffic_ops/go/bin.   The rpm 
> upgrade path executes `db/admin.pl upgrade` which tries to run goose,   but 
> can't find it because it's not in the root PATH.



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

[jira] [Updated] (TC-377) Default profiles for EDGE and MID are missing after initial install

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-377:
---
Labels: profiles  (was: )

> Default profiles for EDGE and MID are missing after initial install
> ---
>
> Key: TC-377
> URL: https://issues.apache.org/jira/browse/TC-377
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Jan van Doorn
>Assignee: Jan van Doorn
>  Labels: profiles
> Fix For: 2.1.0
>
>
> I suggest we don't add these to the seeds, but create a "profile exchange" 
> that people can dl the right profile from. 
> I'll take a first stab at this.



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

[jira] [Updated] (TC-380) Integration test data for kabletown has bad regex types

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-380:
---
Labels: integration-test  (was: )

> Integration test data for kabletown has bad regex types
> ---
>
> Key: TC-380
> URL: https://issues.apache.org/jira/browse/TC-380
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>Priority: Critical
>  Labels: integration-test
> Fix For: 2.1.0
>
>




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

[jira] [Updated] (TC-381) postinstall errors if "secrets" is missing from cdn.conf

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-381:
---
Labels: cdn.conf postinstall  (was: )

> postinstall errors if "secrets" is missing from cdn.conf
> 
>
> Key: TC-381
> URL: https://issues.apache.org/jira/browse/TC-381
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0, 2.1.0
> Environment: CentOS 7.3
>Reporter: Hank Beatty
>  Labels: cdn.conf, postinstall
>
> Our cdn.conf file doesn't have the "secrets" section. The postinstall script 
> doesn't handle this gracefully.



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

[jira] [Updated] (TC-382) If postinstall is run more than once it errors on one of the DB Inserts

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-382:
---
Labels: postinstall  (was: )

> If postinstall is run more than once it errors on one of the DB Inserts
> ---
>
> Key: TC-382
> URL: https://issues.apache.org/jira/browse/TC-382
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
> Environment: CentOS 7.3
> PostgreSQL 9.6 (running on separate VM)
>Reporter: Hank Beatty
>Priority: Critical
>  Labels: postinstall
>




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

[jira] [Updated] (TC-385) IPv6 Origin Configuration Not Allowed

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-385:
---
 Labels: ipv6 origin  (was: )
Summary: IPv6 Origin Configuration Not Allowed  (was: Traffic Ops does not 
allow configuration of IPv6 origin)

> IPv6 Origin Configuration Not Allowed
> -
>
> Key: TC-385
> URL: https://issues.apache.org/jira/browse/TC-385
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>  Labels: ipv6, origin
>
> IPv6 origins need to be configured using brackets if using the IP (such as 
> http://[fec0::250:56ff:fea9:172]), but Traffic Ops rejects it with error:
> [fec0 is not a valid org server name (rfc1123) or :250:56ff:fea9:172] is not 
> a valid port



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

[jira] [Updated] (TC-386) Update traffic ops docker image

[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:
---
Labels: build docker  (was: )

> 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
>  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)

[GitHub] incubator-trafficcontrol pull request #673: add building doc to development ...

[dangogh]

GitHub user dangogh opened a pull request:

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

add building doc to development page



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

$ git pull https://github.com/dangogh/incubator-trafficcontrol docs-building

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

https://github.com/apache/incubator-trafficcontrol/pull/673.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 #673


commit 07033d6dc7b93d8aa45b602cd941fbaab491a226
Author: Dan Kirkwood 
Date:   2017-06-13T19:38:39Z

add building doc to development page




---
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] [Created] (TC-388) Max IP Address in DNS Answer Behavior Change

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-388:
--

 Summary: Max IP Address in DNS Answer 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


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] [Created] (TC-387) Dynamic assignment of max-ip address in DNS answer parameter for DNS routed services

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-387:
--

 Summary: Dynamic assignment of max-ip address in DNS answer 
parameter for DNS routed services
 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


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. 



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

[jira] [Updated] (TC-199) Configurable consistent hash attributes for cache selection

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-199:
---
Labels: configuration routing  (was: )

> Configurable consistent hash attributes for cache selection
> ---
>
> Key: TC-199
> URL: https://issues.apache.org/jira/browse/TC-199
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Router
>Affects Versions: 2.1.0
>Reporter: Jeff Elsloo
>Priority: Minor
>  Labels: configuration, routing
>
> Add a feature to Traffic Router and Traffic Ops that allows one to specify 
> attributes to use when consistent hashing for cache selection on a 
> per-delivery service basis. One specific use case is to allow us to consider 
> the query string, as the default is to ignore it. Beyond that, we might want 
> to allow additional strategies, such as a regex that will match parts of the 
> attribute (path, header), or allow URL + header, header only, etc.



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

[jira] [Closed] (TC-208) Purge - Expand invalidation to purge

[Ryan Durfey (JIRA)]

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

Ryan Durfey closed TC-208.
--
Resolution: Duplicate

Duplicate of TC-213

> Purge - Expand invalidation to purge
> 
>
> Key: TC-208
> URL: https://issues.apache.org/jira/browse/TC-208
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Ryan Durfey
>
> Current invalidation functionality only invalidates the resource in cache and 
> does not actually delete it from cache.  Tenants sometimes need the ability 
> to fully remove an object from cache.
> Build an API which allows users to fully purge/delete objects which operates 
> similar to the current invalidation API.  
> We recognize that wildcards may pose technical issues with purge based on the 
> way that objects are stored via url hash.



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

[jira] [Assigned] (TC-212) Portal - Configurable Dashboards

[Ryan Durfey (JIRA)]

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

Ryan Durfey reassigned TC-212:
--

Assignee: Jeremy Mitchell

> Portal - Configurable Dashboards
> 
>
> Key: TC-212
> URL: https://issues.apache.org/jira/browse/TC-212
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Portal
>Reporter: Ashish Timilsina
>Assignee: Jeremy Mitchell
>  Labels: chart, portal, self_service
>
> Create a framework in the CDN Portal so that users have a base set of 
> dashboards that they inherit, and can then create new dashboards based on any 
> service data available to them.
> *Allow users to CRUD dashboards.
> *Allow users to save these dashboards.
> *Allow users to share dashboards they have created with other users so they 
> can save to their account.
> The vision is something along the lines of what Kibana or Grafana already do. 
> May require some query language to be used to create the dashboard.



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

[jira] [Assigned] (TC-213) Purge Functionality - Add to Portal

[Ryan Durfey (JIRA)]

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

Ryan Durfey reassigned TC-213:
--

Assignee: Dylan Volz

> Purge Functionality - Add to Portal
> ---
>
> Key: TC-213
> URL: https://issues.apache.org/jira/browse/TC-213
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Portal
>Reporter: Ashish Timilsina
>Assignee: Dylan Volz
>  Labels: invalidation, portal, purge, self_service
>
> We found that in some cases corrupted content can get trapped in the edge 
> cache with proper ETAGs, so invalidation requests are not able to cause the 
> content to reload. We also found there is a business case to remove content 
> from cache. We need a mechanism that works similar to invalidation but 
> actually purges content from the caches.
> This would be done without wildcards as a restriction.



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

[jira] [Updated] (TC-212) Portal - Configurable Dashboards

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-212:
---
Labels: chart portal self_service  (was: feature portal)

> Portal - Configurable Dashboards
> 
>
> Key: TC-212
> URL: https://issues.apache.org/jira/browse/TC-212
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Portal
>Reporter: Ashish Timilsina
>  Labels: chart, portal, self_service
>
> Create a framework in the CDN Portal so that users have a base set of 
> dashboards that they inherit, and can then create new dashboards based on any 
> service data available to them.
> *Allow users to CRUD dashboards.
> *Allow users to save these dashboards.
> *Allow users to share dashboards they have created with other users so they 
> can save to their account.
> The vision is something along the lines of what Kibana or Grafana already do. 
> May require some query language to be used to create the dashboard.



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

[jira] [Updated] (TC-213) Purge Functionality - Add to Portal

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-213:
---
 Labels: invalidation portal purge self_service  (was: feature portal 
purge)
Description: 
We found that in some cases corrupted content can get trapped in the edge cache 
with proper ETAGs, so invalidation requests are not able to cause the content 
to reload. We also found there is a business case to remove content from cache. 
We need a mechanism that works similar to invalidation but actually purges 
content from the caches.

This would be done without wildcards as a restriction.

  was:We found that in some cases corrupted content can get trapped in the edge 
cache with proper ETAGs, so invalidation requests are not able to cause the 
content to reload. We also found there is a business case to remove content 
from cache. We need a mechanism that works similar to invalidation but actually 
purges content from the caches.


> Purge Functionality - Add to Portal
> ---
>
> Key: TC-213
> URL: https://issues.apache.org/jira/browse/TC-213
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Portal
>Reporter: Ashish Timilsina
>  Labels: invalidation, portal, purge, self_service
>
> We found that in some cases corrupted content can get trapped in the edge 
> cache with proper ETAGs, so invalidation requests are not able to cause the 
> content to reload. We also found there is a business case to remove content 
> from cache. We need a mechanism that works similar to invalidation but 
> actually purges content from the caches.
> This would be done without wildcards as a restriction.



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

[jira] [Updated] (TC-214) SSL Customer Cert Upload

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-214:
---
Labels: self_service ssl  (was: feature)

> SSL Customer Cert Upload
> 
>
> Key: TC-214
> URL: https://issues.apache.org/jira/browse/TC-214
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API, Traffic Vault
>Reporter: Ashish Timilsina
>  Labels: self_service, ssl
>
> Allow CDN tenants to upload a custom cert to the CDN for application to their 
> services.
> Customers that split traffic across multiple CDNs have to use their own FQDN 
> and SSL cert. We need a process for them to securely upload their certs to us 
> for storage and application against their services.
> We also need to capture the FQDN of the cert and make sure it is applied as a 
> host regex for their service so that the CDN recognizes it. It's possible 
> that it is already in place when they upload the cert, but this should be 
> checked.



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

[jira] [Assigned] (TC-216) Chart Add - Unique User Count Chart Added to data API and Traffic Portal Charts

[Ryan Durfey (JIRA)]

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

Ryan Durfey reassigned TC-216:
--

 Assignee: Dylan Volz
Affects Version/s: 2.1.0
   Labels: chart portal  (was: chart feature portal)
  Description: 
Unique user count per minute per delivery service.

Depends upon log data aggregation into time series database.



  was:Average User Throughput and Unique Users

  Component/s: Traffic Ops API
  Summary: Chart Add - Unique User Count Chart Added to data API 
and Traffic Portal Charts  (was: Portal - Add New Charts)

> Chart Add - Unique User Count Chart Added to data API and Traffic Portal 
> Charts
> ---
>
> Key: TC-216
> URL: https://issues.apache.org/jira/browse/TC-216
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API, Traffic Portal
>Affects Versions: 2.1.0
>Reporter: Ashish Timilsina
>Assignee: Dylan Volz
>  Labels: chart, portal
>
> Unique user count per minute per delivery service.
> Depends upon log data aggregation into time series database.



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

[jira] [Updated] (TC-217) CRUD Tenant - Self-service

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-217:
---
 Labels: configuration self_service tenant  (was: )
Summary: CRUD Tenant - Self-service  (was: Self Service - CRUD Sub Tenant)

> CRUD Tenant - Self-service
> --
>
> Key: TC-217
> URL: https://issues.apache.org/jira/browse/TC-217
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Ashish Timilsina
>  Labels: configuration, self_service, tenant
>
> Allow users to CRUD sub tenants below their tenant level or below any 
> sub-tenant level they choose. Default would be directly below the current 
> tenant value.



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

[jira] [Updated] (TC-219) CRUD Delivery Service - Self Service

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-219:
---
 Labels: configuration self_service  (was: )
Summary: CRUD Delivery Service - Self Service  (was: Self Service - CRUD 
Delivery Service)

> CRUD Delivery Service - Self Service
> 
>
> Key: TC-219
> URL: https://issues.apache.org/jira/browse/TC-219
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Ashish Timilsina
>  Labels: configuration, self_service
>
> Allow customers to CRUD delivery services via the API and Portal accessing 
> all available features and configurations.



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

[jira] [Updated] (TC-218) CRUD Users - Self-Service

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-218:
---
 Labels: configuration self_service users  (was: self_service users)
Summary: CRUD Users - Self-Service  (was: Self Service - CRUD Users)

> CRUD Users - Self-Service
> -
>
> Key: TC-218
> URL: https://issues.apache.org/jira/browse/TC-218
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Ashish Timilsina
>  Labels: configuration, self_service, users
>
> Allow customer (admin roles only) to CRUD users.
> 1. Creator gets to choose tenant assignment based on any available tenant to 
> the user, default will be for same tenant as the creator.
> 2. Creator can sets role for user, default is read only.



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

[jira] [Commented] (TC-382) If postinstall is run more than once it errors on one of the DB Inserts

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-382:


I don't think this applies to 2.1.

in the _postinstall around line 698 the following INSERTS are run:

{{insert into parameter (name, config_file, value) 
values ('tm.url', 'global', '$tm_url') 
ON CONFLICT DO NOTHING;

insert into parameter (name, config_file, value) 
values ('tm.infourl', 'global', '$tm_url/doc') 
ON CONFLICT DO NOTHING;

-- CRConfig.json parameters
insert into parameter (name, config_file, value) 
values ('geolocation.polling.url', 'CRConfig.json', 
'$tm_url/routing/GeoLite2-City.mmdb.gz') 
ON CONFLICT DO NOTHING;

insert into parameter (name, config_file, value) 
values ('geolocation6.polling.url', 'CRConfig.json', 
'$tm_url/routing/GeoLiteCityv6.dat.gz') 
ON CONFLICT DO NOTHING;
}}

The following doesn't seem to be applied in 2.0:

ALTER TABLE parameter ADD CONSTRAINT unique_param UNIQUE (name, config_file, 
value);

Once that is there the ON CONFLICT can be changed.

> If postinstall is run more than once it errors on one of the DB Inserts
> ---
>
> Key: TC-382
> URL: https://issues.apache.org/jira/browse/TC-382
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
> Environment: CentOS 7.3
> PostgreSQL 9.6 (running on separate VM)
>Reporter: Hank Beatty
>Priority: Critical
>




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

[jira] [Updated] (TC-239) Validation rules for delivery service regex

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-239:
---
 Labels: configuration regex validation  (was: )
Component/s: Traffic Ops
Summary: Validation rules for delivery service regex  (was: TO API - 
Enforce validation rules when updating a deliveryservice regex)

> Validation rules for delivery service regex
> ---
>
> Key: TC-239
> URL: https://issues.apache.org/jira/browse/TC-239
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Jeremy Mitchell
>  Labels: configuration, regex, validation
> Fix For: 2.1.0
>
>
> The following rules need to be enforced in the deliveryservice regex apis:
> 1. POST /api/../deliveryservices/:dsId/regexes (create ds regex)
> - you can't create a ds regex at position 0 because it was already created 
> for you when you created the ds and there can only be 1 regex at position 0.
> 2. PUT /api/../deliveryservices/:dsId/regexes/:id (update ds regex)
> - can't edit a ds regex to have set_number=0 (there can only be one and it 
> already exists)
> - can't update the set_number of the regex at position zero. 
> - the format of the ds regex at position zero must be validated to 
> .**\something\..**
> - if the pattern of the regex at position zero changes, then dnssec keys must 
> be recreated if the ds is part of a dnssecenabled cdn
> 3. DELETE /api/../deliveryservices/:dsId/regexes/:id (delete ds regex)
> - can't delete the regex at position zero



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

[jira] [Updated] (TC-252) Child server updates - Enhance POST /api/$version/servers/:id/queue_update to queue child servers only

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-252:
---
Affects Version/s: 2.1.0
   Labels: cache_updates  (was: )
Fix Version/s: (was: 2.1.0)
  Component/s: Traffic Ops
  Summary:  Child server updates - Enhance POST 
/api/$version/servers/:id/queue_update to queue child servers only  (was: TO 
API - enhance POST /api/$version/servers/:id/queue_update to queue child 
servers only)

>  Child server updates - Enhance POST /api/$version/servers/:id/queue_update 
> to queue child servers only
> ---
>
> Key: TC-252
> URL: https://issues.apache.org/jira/browse/TC-252
> 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: cache_updates
>
> Provide the ability to queue updates on a cache's children caches (aka the 
> caches that belong to that cache's child cache groups.)
> This is needed when a cache is set to admin down and all the child caches 
> will need to fetch updates to get the change to parent.config (which will 
> exclude the parent cache).
> The support of a request property like { "childrenOnly":true } would suffice. 
> So you'd have a call like this:
> POST /api/$version/servers/:id/queue_update { "action": "queue", 
> "childrenOnly": true }
> to queue the updates of the children caches only (not the parent cache).



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

[jira] [Closed] (TC-253) TO API - create API endpoint for changing server status

[Ryan Durfey (JIRA)]

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

Ryan Durfey closed TC-253.
--
   Resolution: Duplicate
Fix Version/s: (was: 2.1.0)

Duplicated of TC-362

> TO API - create API endpoint for changing server status
> ---
>
> Key: TC-253
> URL: https://issues.apache.org/jira/browse/TC-253
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> The API could look like this:
> PUT api/$version/servers/:id/status and include a request payload like:
> { "statusId": 1, "offlineReason": "foo bar" }
> If status is OFFLINE or ADMIN_DOWN, then offlineReason is required.
> This api should be limited to ops or above.
> Changing the status of a server should also queue updates on child caches IF 
> the server type is ^EDGE* or ^MID*. This is needed because when you change 
> the status of server, the parent.config file of the children servers (servers 
> that are in a child cache group) is affected.



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

[jira] [Updated] (TC-300) Combine cache key change and dropping of query strings

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-300:
---
Labels: cache_key configuration query_strings  (was: Configuration)

> Combine cache key change and dropping of query strings
> --
>
> Key: TC-300
> URL: https://issues.apache.org/jira/browse/TC-300
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops
>Reporter: Matt Mills
>Priority: Minor
>  Labels: cache_key, configuration, query_strings
>
> https://github.com/Comcast/traffic_control/issues/511
> mtorluemke commented on Sep 11, 2015
> Not sure exactly how best to do this. Perhaps:
> Get rid of the drop_qstring column, and beef up the 'recipes' for the 
> cacheurl field.
> Add 'cache_key_string' column, and add smarts to combine the two when both 
> fields are set.



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

[jira] [Commented] (TC-362) TO API - create API endpoint to update server status

[Ryan Durfey (JIRA)]

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

Ryan Durfey commented on TC-362:


Can this be resolved or closed?


> TO API - create API endpoint to update server status
> 
>
> Key: TC-362
> URL: https://issues.apache.org/jira/browse/TC-362
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
>
> PUT /api/1.2/servers/:id/status
> { status: id/name, offlineReason: '' }
> if status is OFFLINE or ADMIN_DOWN, then offlineReason is required.
> if server.type is ^EDGE or ^MID, then queue updates on server plus children



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

[jira] [Updated] (TC-382) If postinstall is run more than once it errors on one of the DB Inserts

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-382:
---
Affects Version/s: (was: 2.1.0)

> If postinstall is run more than once it errors on one of the DB Inserts
> ---
>
> Key: TC-382
> URL: https://issues.apache.org/jira/browse/TC-382
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.0.0
> Environment: CentOS 7.3
> PostgreSQL 9.6 (running on separate VM)
>Reporter: Hank Beatty
>Priority: Critical
>




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

[jira] [Updated] (TC-376) Steering services feature additions

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-376:
---
Labels: configuration steering  (was: Configuration)

> Steering services feature additions
> ---
>
> Key: TC-376
> URL: https://issues.apache.org/jira/browse/TC-376
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops
>Reporter: Derek Gelinas
>  Labels: configuration, steering
>
> Steering services need to be able to set order or weight for their targets.  
> Order can be any whole integer, weight must be a whole integer equal or 
> greater than 0.
> We also need to provide the ability to add more than 2 targets per steering 
> service.
> Documentation on Steering Services
> http://trafficcontrol.apache.org/docs/latest/admin/quick_howto/steering.html?highlight=steering%20service



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

[jira] [Updated] (TC-275) Traffic Ops - Export/Import delivery service

[Ryan Durfey (JIRA)]

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

Ryan Durfey updated TC-275:
---
 Labels: configuration testing  (was: )
Component/s: (was: Traffic Ops Client )

> Traffic Ops - 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
>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] [Assigned] (TC-386) Update traffic ops docker image

[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

[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)

[jira] [Commented] (TC-356) license cleanup for vendored files

[ASF GitHub Bot (JIRA)]

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

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

Github user dangogh closed the pull request at:

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


> license cleanup for vendored files
> --
>
> Key: TC-356
> URL: https://issues.apache.org/jira/browse/TC-356
> Project: Traffic Control
>  Issue Type: Task
>  Components: Release, Traffic Ops, Traffic Stats
>Affects Versions: 2.0.0, 2.1.0
>Reporter: Dan Kirkwood
>  Labels: license
>
> The following list of files are signaled by apache-rat as not having 
> Apache-compatible licenses.  Some need the license to be added while others 
> may need to be added to the .rat-excludes file:
> * BUILD_NUMBER
> * traffic_ops/experimental/auth/server.key
> * traffic_ops/experimental/ui/app/src/common/modules/table/_table.scss
> * 
> traffic_ops/experimental/ui/app/src/common/modules/widget/cacheGroups/_widget.cacheGroups.scss
> * 
> traffic_ops/experimental/ui/app/src/common/modules/widget/capacity/_widget.capacity.scss
> * 
> traffic_ops/experimental/ui/app/src/common/modules/widget/routing/_widget.routing.scss
> * traffic_ops/experimental/ui/app/src/styles/loading.scss
> * traffic_ops/experimental/ui/app/src/styles/theme.scss
> * traffic_ops/experimental/webfront/server.key
> * traffic_ops/experimental/webfront/simpleserver/server.key
> * traffic_portal/app/src/styles/loading.scss
> * traffic_stats/vendor/github.com/influxdata/influxdb/client/v2/client.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/client/v2/udp.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/consistency.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/inline_fnv.go
> * 
> traffic_stats/vendor/github.com/influxdata/influxdb/models/inline_strconv_parse.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/points.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/rows.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/statistic.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/time.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/pkg/escape/bytes.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/pkg/escape/strings.go
> * traffic_stats/vendor/github.com/pkg/errors/appveyor.yml
> * traffic_stats/vendor/github.com/pkg/errors/errors.go
> * traffic_stats/vendor/github.com/pkg/errors/stack.go
> * traffic_stats/vendor/golang.org/x/net/PATENTS
> * traffic_stats/vendor/golang.org/x/net/publicsuffix/gen.go
> * traffic_stats/vendor/golang.org/x/net/publicsuffix/list.go
> * traffic_stats/vendor/golang.org/x/net/publicsuffix/table.go



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

[GitHub] incubator-trafficcontrol pull request #671: [Backport TC-356] update .rat-ex...

[dangogh]

Github user dangogh closed the pull request at:

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


---
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.
---

Build failed in Jenkins: incubator-trafficcontrol-2.0.x-rat #3

[Apache Jenkins Server]

See 


--
Started by upstream project "incubator-trafficcontrol-2.0.x-build" build number 
11
originally caused by:
 Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-eu2 (ubuntu trusty) in workspace 

[incubator-trafficcontrol-2.0.x-rat] $ /bin/bash -xe 
/tmp/hudson1778676300365051963.sh
+ rm -rf 
' 
'
[operations-center-context] Requesting copy of artifacts matching '**/*.tar.gz' 
from 'Last successful build (either stable or unstable)' of 
incubator-trafficcontrol-2.0.x-build
[operations-center-context] Copied 1 artifacts matching '**/*.tar.gz' from 
'Last successful build (either stable or unstable)' of 
incubator-trafficcontrol-2.0.x-build:
[operations-center-context]   trafficcontrol-incubating-2.0.0.tar.gz
[incubator-trafficcontrol-2.0.x-rat] $ /bin/bash -xe 
/tmp/hudson2638124425133930598.sh
+ set -exu
++ ls trafficcontrol-incubating-2.0.0.tar.gz
+ tarball=trafficcontrol-incubating-2.0.0.tar.gz
+ tar xzf trafficcontrol-incubating-2.0.0.tar.gz
++ pwd
++ basename trafficcontrol-incubating-2.0.0.tar.gz .tar.gz
+ 
tcdir=
+ cd 

++ date +%Y
+ grep 'Copyright 2017 The Apache Software Foundation' NOTICE
Copyright 2017 The Apache Software Foundation
+ set +x
Searching for class files:
PASSED: No class files found.
Searching for jar files:
PASSED: No jar files found.
Searching for tar files:
PASSED: No tar files found.
Searching for tgz files:
PASSED: No tgz files found.
Searching for zip files:
PASSED: No zip files found.
+ ratver=apache-rat-0.13-20170427.032418-37.jar
++ mktemp -d
+ ratdir=/tmp/tmp.FUTKEbjftl
+ ratjar=/tmp/tmp.FUTKEbjftl/apache-rat-0.13.SNAPSHOT.jar
+ curl -L -o /tmp/tmp.FUTKEbjftl/apache-rat-0.13.SNAPSHOT.jar 
https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/0.13-SNAPSHOT/apache-rat-0.13-20170427.032418-37.jar
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0 
27 1587k   27  431k0 0   479k  0  0:00:03 --:--:--  0:00:03  
479k100 1587k  100 1587k0 0  1476k  0  0:00:01  0:00:01 --:--:-- 
1477k
+ curl -L -o /tmp/tmp.FUTKEbjftl/apache-rat-0.13.SNAPSHOT.jar.sha1 
https://repository.apache.org/content/repositories/snapshots/org/apache/rat/apache-rat/0.13-SNAPSHOT/apache-rat-0.13-20170427.032418-37.jar.sha1
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
010040  100400 0 98  0 --:--:-- --:--:-- --:--:--98
++ sha1sum /tmp/tmp.FUTKEbjftl/apache-rat-0.13.SNAPSHOT.jar
++ awk '{print $1}'
++ cat /tmp/tmp.FUTKEbjftl/apache-rat-0.13.SNAPSHOT.jar.sha1
+ [[ ac5cfd859902d5c858baed8dbcf91c014ce9ae23 == 
ac5cfd859902d5c858baed8dbcf91c014ce9ae23 ]]
++ pwd
++ pwd
+ java -jar /tmp/tmp.FUTKEbjftl/apache-rat-0.13.SNAPSHOT.jar -E 

 -d 

+ rm -rf /tmp/tmp.FUTKEbjftl
++ perl -lne 'print if /\(\d+\) Unknown Licenses/' ratreport.txt
+ unknown=
+ [[ '' != 0 ]]
+ echo ' Unknown Licenses'
 Unknown Licenses
+ perl -lne 'print if /Files with unapproved licenses:/ .. /^\*\*\*/' 
ratreport.txt
+ sed s:::
Files with unapproved licenses:

  
trafficcontrol-incubating-2.0.0/traffic_ops/experimental/ui/app/src/styles/theme.scss
  trafficcontrol-incubating-2.0.0/traffic_ops/install/bin/todb_bootstrap.sh

*
+ exit 1
Build step 'Execute shell' marked build as failure
Archiving artifacts
No prior successful build to compare, so performing full copy of artifacts

[GitHub] incubator-trafficcontrol issue #671: [Backport TC-356] update .rat-excludes ...

[limited]

Github user limited commented on the issue:

https://github.com/apache/incubator-trafficcontrol/pull/671
  
merged. 


---
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-356) license cleanup for vendored files

[ASF GitHub Bot (JIRA)]

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

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

Github user limited commented on the issue:

https://github.com/apache/incubator-trafficcontrol/pull/671
  
merged. 


> license cleanup for vendored files
> --
>
> Key: TC-356
> URL: https://issues.apache.org/jira/browse/TC-356
> Project: Traffic Control
>  Issue Type: Task
>  Components: Release, Traffic Ops, Traffic Stats
>Affects Versions: 2.0.0, 2.1.0
>Reporter: Dan Kirkwood
>  Labels: license
>
> The following list of files are signaled by apache-rat as not having 
> Apache-compatible licenses.  Some need the license to be added while others 
> may need to be added to the .rat-excludes file:
> * BUILD_NUMBER
> * traffic_ops/experimental/auth/server.key
> * traffic_ops/experimental/ui/app/src/common/modules/table/_table.scss
> * 
> traffic_ops/experimental/ui/app/src/common/modules/widget/cacheGroups/_widget.cacheGroups.scss
> * 
> traffic_ops/experimental/ui/app/src/common/modules/widget/capacity/_widget.capacity.scss
> * 
> traffic_ops/experimental/ui/app/src/common/modules/widget/routing/_widget.routing.scss
> * traffic_ops/experimental/ui/app/src/styles/loading.scss
> * traffic_ops/experimental/ui/app/src/styles/theme.scss
> * traffic_ops/experimental/webfront/server.key
> * traffic_ops/experimental/webfront/simpleserver/server.key
> * traffic_portal/app/src/styles/loading.scss
> * traffic_stats/vendor/github.com/influxdata/influxdb/client/v2/client.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/client/v2/udp.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/consistency.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/inline_fnv.go
> * 
> traffic_stats/vendor/github.com/influxdata/influxdb/models/inline_strconv_parse.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/points.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/rows.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/statistic.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/models/time.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/pkg/escape/bytes.go
> * traffic_stats/vendor/github.com/influxdata/influxdb/pkg/escape/strings.go
> * traffic_stats/vendor/github.com/pkg/errors/appveyor.yml
> * traffic_stats/vendor/github.com/pkg/errors/errors.go
> * traffic_stats/vendor/github.com/pkg/errors/stack.go
> * traffic_stats/vendor/golang.org/x/net/PATENTS
> * traffic_stats/vendor/golang.org/x/net/publicsuffix/gen.go
> * traffic_stats/vendor/golang.org/x/net/publicsuffix/list.go
> * traffic_stats/vendor/golang.org/x/net/publicsuffix/table.go



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

[jira] [Commented] (TC-385) Traffic Ops does not allow configuration of IPv6 origin

[ASF GitHub Bot (JIRA)]

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

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

GitHub user zhilhuan opened a pull request:

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

[TC-385] check origin host name is IPv6 address



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

$ git pull https://github.com/zhilhuan/incubator-trafficcontrol TC-385

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

https://github.com/apache/incubator-trafficcontrol/pull/672.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 #672


commit 2192239d5e5a5eb3b890ad412f8f65ae335f0be6
Author: Zhilin Huang 
Date:   2017-06-13T08:52:46Z

check origin host name is IPv6 address




> Traffic Ops does not allow configuration of IPv6 origin
> ---
>
> Key: TC-385
> URL: https://issues.apache.org/jira/browse/TC-385
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Reporter: Zhilin Huang
>Assignee: Zhilin Huang
>
> IPv6 origins need to be configured using brackets if using the IP (such as 
> http://[fec0::250:56ff:fea9:172]), but Traffic Ops rejects it with error:
> [fec0 is not a valid org server name (rfc1123) or :250:56ff:fea9:172] is not 
> a valid port



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

[jira] [Created] (TC-385) Traffic Ops does not allow configuration of IPv6 origin

[Zhilin Huang (JIRA)]

Zhilin Huang created TC-385:
---

 Summary: Traffic Ops does not allow configuration of IPv6 origin
 Key: TC-385
 URL: https://issues.apache.org/jira/browse/TC-385
 Project: Traffic Control
  Issue Type: Bug
  Components: Traffic Ops
Reporter: Zhilin Huang
Assignee: Zhilin Huang


IPv6 origins need to be configured using brackets if using the IP (such as 
http://[fec0::250:56ff:fea9:172]), but Traffic Ops rejects it with error:

[fec0 is not a valid org server name (rfc1123) or :250:56ff:fea9:172] is not a 
valid port



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