[jira] [Assigned] (TC-516) Deleting a DS thru the API should also delete all SSL keys (if applicable)
[ https://issues.apache.org/jira/browse/TC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-516: -- Assignee: Jeremy Mitchell > Deleting a DS thru the API should also delete all SSL keys (if applicable) > -- > > Key: TC-516 > URL: https://issues.apache.org/jira/browse/TC-516 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell > Fix For: 2.1.0, 2.2.0 > > > There are currently 4 protocols for a DS: > 0 - HTTP > 1 - HTTPS > 2 - HTTP AND HTTPS > 3 - HTTP TO HTTPS > Currently, if you delete a DS thru the API, SSL keys are not deleted. This > should occur if ds.protocol > 0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-420) TPv2 - Add SSH links to server pages
[ https://issues.apache.org/jira/browse/TC-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-420. Resolution: Fixed Fix Version/s: 2.2.0 > TPv2 - Add SSH links to server pages > > > Key: TC-420 > URL: https://issues.apache.org/jira/browse/TC-420 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.2.0 > > > Add SSH links to server pages to enable the ability to quickly SSH into a > server. Server pages include: > http://localhost:8080/#!/configure/servers > http://localhost:8080/#!/admin/cdns/:id/servers > http://localhost:8080/#!/admin/profiles/:id/servers > http://localhost:8080/#!/admin/statuses/:id/servers > http://localhost:8080/#!/admin/types/:id/servers > http://localhost:8080/#!/configure/cache-groups/:id/servers > http://localhost:8080/#!/configure/delivery-services/:id/servers > http://localhost:8080/#!/admin/phys-locations/:id/servers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-520) TPv2 - add the ability to see all delivery services for each tenant
[ https://issues.apache.org/jira/browse/TC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-520. Resolution: Fixed Fix Version/s: 2.2.0 > TPv2 - add the ability to see all delivery services for each tenant > --- > > Key: TC-520 > URL: https://issues.apache.org/jira/browse/TC-520 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.2.0 > > > Delivery services are grouped by tenant. Add the ability to see all ds's for > each tenant. This will help tenancy management. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-483) TPv2 / TO API - make tenant a required field on delivery service
[ https://issues.apache.org/jira/browse/TC-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-483. Resolution: Fixed Assignee: Jeremy Mitchell Fix Version/s: 2.2.0 > TPv2 / TO API - make tenant a required field on delivery service > > > Key: TC-483 > URL: https://issues.apache.org/jira/browse/TC-483 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.2.0 > > > Currently, the tenant_id on a delivery service create or update is optional > in the Traffic Portal and the TO API. This presents a risk because failure to > set the ds.tenant_id will allow all users to see that delivery service. This > may include users that should have no access to this delivery service. > I suggest we make this a required field on create or update of a ds. At some > point tenancy will be required but in the interim tenancy can be turned off > using the use-tenancy=0 parameter. > If the desire is to not use tenancy, you can still set the ds.tenant = root > tenant (which is provided via seeds.sql) and use-tenancy=0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-553) Queue updates API queues updates on all servers, not just caches
[
https://issues.apache.org/jira/browse/TC-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16141847#comment-16141847
]
Jeremy Mitchell commented on TC-553:
this is the api - post("/api/$version/cdns/:id/queue_update
> Queue updates API queues updates on all servers, not just caches
>
>
> Key: TC-553
> URL: https://issues.apache.org/jira/browse/TC-553
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Reporter: David Neuman
>Priority: Minor
>
> If you use the API to queue updates for a CDN it queues updates for all
> servers. It should only queue updates for caches. This doesn't really cause
> any harm, but it's not correct and it makes it so that the other components
> (TR, TM, etc) show up as queued in the UI, which is annoying.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-552) Global parameters may be duplicated when seeds.sql is run
[ https://issues.apache.org/jira/browse/TC-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell updated TC-552: --- Affects Version/s: 2.1.0 > Global parameters may be duplicated when seeds.sql is run > - > > Key: TC-552 > URL: https://issues.apache.org/jira/browse/TC-552 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell >Priority: Minor > > If seeds.sql is run multiple times (i.e. on first install and subsequent > upgrades), the following global parameters may end up duplicated: > https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/db/seeds.sql#L36-L43 > For example, if you change the value of use_tenancy from 0 to 1 and then run > db/admin.pl upgrade you will end up with 2 parameters for use_tenancy > Potential solution: check to see if those 3 global parameters are already in > the db, and if not, insert, else do nothing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-552) Global parameters may be duplicated when seeds.sql is run
Jeremy Mitchell created TC-552: -- Summary: Global parameters may be duplicated when seeds.sql is run Key: TC-552 URL: https://issues.apache.org/jira/browse/TC-552 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Reporter: Jeremy Mitchell Priority: Minor If seeds.sql is run multiple times (i.e. on first install and subsequent upgrades), the following global parameters may end up duplicated: https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/db/seeds.sql#L36-L43 For example, if you change the value of use_tenancy from 0 to 1 and then run db/admin.pl upgrade you will end up with 2 parameters for use_tenancy Potential solution: check to see if those 3 global parameters are already in the db, and if not, insert, else do nothing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-535) DS URL sig key apis needs to have tenancy check in place
[
https://issues.apache.org/jira/browse/TC-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Mitchell reassigned TC-535:
--
Assignee: Nir Sopher (was: Jeremy Mitchell)
> DS URL sig key apis needs to have tenancy check in place
>
>
> Key: TC-535
> URL: https://issues.apache.org/jira/browse/TC-535
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Nir Sopher
> Fix For: 2.1.0, 2.2.0
>
>
> Tenancy was introduced in 2.1, however, by default it is turned off via the
> use_tenancy parameter but when activated it is used to limit the scope of
> delivery services that a user can act on.
> The following APIs needs to check tenancy to ensure users cannot act on ds's
> that they don't have access to.
> post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/generate
> post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/copyFromXmlId/:copyFromXmlId
> get("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (TC-435) TPv2 - add the ability to clone DS assignments from one server to another
[ https://issues.apache.org/jira/browse/TC-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-435: -- Assignee: (was: Jeremy Mitchell) > TPv2 - add the ability to clone DS assignments from one server to another > - > > Key: TC-435 > URL: https://issues.apache.org/jira/browse/TC-435 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Priority: Minor > > Add the ability to clone DS assignments from one server to another. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TC-550) TO API - fetch deliveryservices for a user should have tenancy hooked in
[ https://issues.apache.org/jira/browse/TC-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16140350#comment-16140350 ] Jeremy Mitchell edited comment on TC-550 at 8/24/17 5:26 PM: - the intent of api/version/users/:id/deliveryservices is to show the deliveryservices that a user can interact with. this used to be simply reading the ds/user table to see which ds's were explicitly assigned to the user but now with tenancy that has changed. with use-tenancy=0, that means show the contents of deliveryservice_tmuser for that user with use-tenancy=1, that means show all the ds’s associated with the tenants in the users tenant tree was (Author: mitchell...@apache.org): the intent of api/version/users/:id/deliveryservices is to show the deliveryservices that a user can interact with. this used to be simply reading the ds/user table but now with tenancy that has changed. with use-tenancy=0, that means show the contents of deliveryservice_tmuser for that user with use-tenancy=1, that means show all the ds’s associated with the tenants in the users tenant tree > TO API - fetch deliveryservices for a user should have tenancy hooked in > > > Key: TC-550 > URL: https://issues.apache.org/jira/browse/TC-550 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell > > The following api route does not take into consideration the tenancy of the > specified user: > get( "/api/$version/users/:id/deliveryservices > it currently does the following: > 1. it checks the tenancy of the specified user vs. the tenancy of the current > user to ensure the current user can see the specified user <-- this is good > 2. it queries the deliveryservice_tmuser table to find the delivery services > associated to the tm_user and then if finally filters the results based on > the current user's tenancy <-- it should not query this table if use_tenancy > = 1 > if use_tenancy = 0, it should work the way it does now > if use_tenancy = 1, it should not query the deliveryservice_tmuser table but > instead query the deliveryservice table and filter the results against the > specified user's tenant AND the current user's tenant. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-550) TO API - fetch deliveryservices for a user should have tenancy hooked in
[ https://issues.apache.org/jira/browse/TC-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-550: -- Assignee: Nir Sopher > TO API - fetch deliveryservices for a user should have tenancy hooked in > > > Key: TC-550 > URL: https://issues.apache.org/jira/browse/TC-550 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell >Assignee: Nir Sopher > > The following api route does not take into consideration the tenancy of the > specified user: > get( "/api/$version/users/:id/deliveryservices > it currently does the following: > 1. it checks the tenancy of the specified user vs. the tenancy of the current > user to ensure the current user can see the specified user <-- this is good > 2. it queries the deliveryservice_tmuser table to find the delivery services > associated to the tm_user and then if finally filters the results based on > the current user's tenancy <-- it should not query this table if use_tenancy > = 1 > if use_tenancy = 0, it should work the way it does now > if use_tenancy = 1, it should not query the deliveryservice_tmuser table but > instead query the deliveryservice table and filter the results against the > specified user's tenant AND the current user's tenant. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-550) TO API - fetch deliveryservices for a user should have tenancy hooked in
[ https://issues.apache.org/jira/browse/TC-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16140350#comment-16140350 ] Jeremy Mitchell commented on TC-550: the intent of api/version/users/:id/deliveryservices is to show the deliveryservices that a user can interact with. this used to be simply reading the ds/user table but now with tenancy that has changed. with use-tenancy=0, that means show the contents of deliveryservice_tmuser for that user with use-tenancy=1, that means show all the ds’s associated with the tenants in the users tenant tree > TO API - fetch deliveryservices for a user should have tenancy hooked in > > > Key: TC-550 > URL: https://issues.apache.org/jira/browse/TC-550 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell > > The following api route does not take into consideration the tenancy of the > specified user: > get( "/api/$version/users/:id/deliveryservices > it currently does the following: > 1. it checks the tenancy of the specified user vs. the tenancy of the current > user to ensure the current user can see the specified user <-- this is good > 2. it queries the deliveryservice_tmuser table to find the delivery services > associated to the tm_user and then if finally filters the results based on > the current user's tenancy <-- it should not query this table if use_tenancy > = 1 > if use_tenancy = 0, it should work the way it does now > if use_tenancy = 1, it should not query the deliveryservice_tmuser table but > instead query the deliveryservice table and filter the results against the > specified user's tenant AND the current user's tenant. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-551) TO API - add the ability to filter parameters by name or config file
Jeremy Mitchell created TC-551: -- Summary: TO API - add the ability to filter parameters by name or config file Key: TC-551 URL: https://issues.apache.org/jira/browse/TC-551 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops API Reporter: Jeremy Mitchell Assignee: Jeremy Mitchell Priority: Minor Examples: /api/1.2/parameters?name=LogFormat.Format /api/1.2/parameters?configFile=records.config -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TC-550) TO API - fetch deliveryservices for a user should have tenancy hooked in
[
https://issues.apache.org/jira/browse/TC-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138965#comment-16138965
]
Jeremy Mitchell edited comment on TC-550 at 8/23/17 7:51 PM:
-
On this line:
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Deliveryservice.pm#L982
maybe it should be something like:
if (!$tenant_utils->is_ds_resource_accessible($tenants_data, $row->tenant_id)
|| !$tenant_utils->is_ds_resource_accessible($tenants_data, $row->tenant_id,
user.tenant_id) ) {
next;
}
I passed in a 3rd optional argument to is_ds_resource_accessible() and
specified the tenant i wanted to have the $row.tenant_id checked against
so in this case, i want tenancy to be checked against the current_user.tenant
AND the user.tenant..
was (Author: mitchell...@apache.org):
On this line:
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Deliveryservice.pm#L982
maybe it should be something like:
if (!$tenant_utils->is_ds_resource_accessible($tenants_data, $row->tenant_id)
&& !$tenant_utils->is_ds_resource_accessible($tenants_data, $row->tenant_id,
user.tenant_id) ) {
next;
}
I passed in a 3rd optional argument to is_ds_resource_accessible() and
specified the tenant i wanted to have the $row.tenant_id checked against
so in this case, i want tenancy to be checked against the current_user.tenant
AND the user.tenant..
> TO API - fetch deliveryservices for a user should have tenancy hooked in
>
>
> Key: TC-550
> URL: https://issues.apache.org/jira/browse/TC-550
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>
> The following api route does not take into consideration the tenancy of the
> specified user:
> get( "/api/$version/users/:id/deliveryservices
> it currently does the following:
> 1. it checks the tenancy of the specified user vs. the tenancy of the current
> user to ensure the current user can see the specified user <-- this is good
> 2. it queries the deliveryservice_tmuser table to find the delivery services
> associated to the tm_user and then if finally filters the results based on
> the current user's tenancy <-- it should not query this table if use_tenancy
> = 1
> if use_tenancy = 0, it should work the way it does now
> if use_tenancy = 1, it should not query the deliveryservice_tmuser table but
> instead query the deliveryservice table and filter the results against the
> specified user's tenant AND the current user's tenant.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TC-550) TO API - fetch deliveryservices for a user should have tenancy hooked in
[
https://issues.apache.org/jira/browse/TC-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138965#comment-16138965
]
Jeremy Mitchell commented on TC-550:
On this line:
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Deliveryservice.pm#L982
maybe it should be something like:
if (!$tenant_utils->is_ds_resource_accessible($tenants_data, $row->tenant_id)
&& !$tenant_utils->is_ds_resource_accessible($tenants_data, $row->tenant_id,
user.tenant_id) ) {
next;
}
I passed in a 3rd optional argument to is_ds_resource_accessible() and
specified the tenant i wanted to have the $row.tenant_id checked against
so in this case, i want tenancy to be checked against the current_user.tenant
AND the user.tenant..
> TO API - fetch deliveryservices for a user should have tenancy hooked in
>
>
> Key: TC-550
> URL: https://issues.apache.org/jira/browse/TC-550
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>
> The following api route does not take into consideration the tenancy of the
> specified user:
> get( "/api/$version/users/:id/deliveryservices
> it currently does the following:
> 1. it checks the tenancy of the specified user vs. the tenancy of the current
> user to ensure the current user can see the specified user <-- this is good
> 2. it queries the deliveryservice_tmuser table to find the delivery services
> associated to the tm_user and then if finally filters the results based on
> the current user's tenancy <-- it should not query this table if use_tenancy
> = 1
> if use_tenancy = 0, it should work the way it does now
> if use_tenancy = 1, it should not query the deliveryservice_tmuser table but
> instead query the deliveryservice table and filter the results against the
> specified user's tenant AND the current user's tenant.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-550) TO API - fetch deliveryservices for a user should have tenancy hooked in
Jeremy Mitchell created TC-550: -- Summary: TO API - fetch deliveryservices for a user should have tenancy hooked in Key: TC-550 URL: https://issues.apache.org/jira/browse/TC-550 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Affects Versions: 2.1.0 Reporter: Jeremy Mitchell The following api route does not take into consideration the tenancy of the specified user: get( "/api/$version/users/:id/deliveryservices it currently does the following: 1. it checks the tenancy of the specified user vs. the tenancy of the current user to ensure the current user can see the specified user <-- this is good 2. it queries the deliveryservice_tmuser table to find the delivery services associated to the tm_user and then if finally filters the results based on the current user's tenancy <-- it should not query this table if use_tenancy = 1 if use_tenancy = 0, it should work the way it does now if use_tenancy = 1, it should not query the deliveryservice_tmuser table but instead query the deliveryservice table and filter the results against the specified user's tenant AND the current user's tenant. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-535) DS URL sig key apis needs to have tenancy check in place
[
https://issues.apache.org/jira/browse/TC-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Mitchell reassigned TC-535:
--
Assignee: Jeremy Mitchell (was: Nir Sopher)
> DS URL sig key apis needs to have tenancy check in place
>
>
> Key: TC-535
> URL: https://issues.apache.org/jira/browse/TC-535
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
> Fix For: 2.1.0, 2.2.0
>
>
> Tenancy was introduced in 2.1, however, by default it is turned off via the
> use_tenancy parameter but when activated it is used to limit the scope of
> delivery services that a user can act on.
> The following APIs needs to check tenancy to ensure users cannot act on ds's
> that they don't have access to.
> post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/generate
> post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/copyFromXmlId/:copyFromXmlId
> get("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (TC-420) TPv2 - Add SSH links to server pages
[ https://issues.apache.org/jira/browse/TC-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-420: -- Assignee: Jeremy Mitchell > TPv2 - Add SSH links to server pages > > > Key: TC-420 > URL: https://issues.apache.org/jira/browse/TC-420 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > > Add SSH links to server pages to enable the ability to quickly SSH into a > server. Server pages include: > http://localhost:8080/#!/configure/servers > http://localhost:8080/#!/admin/cdns/:id/servers > http://localhost:8080/#!/admin/profiles/:id/servers > http://localhost:8080/#!/admin/statuses/:id/servers > http://localhost:8080/#!/admin/types/:id/servers > http://localhost:8080/#!/configure/cache-groups/:id/servers > http://localhost:8080/#!/configure/delivery-services/:id/servers > http://localhost:8080/#!/admin/phys-locations/:id/servers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-435) TPv2 - add the ability to clone DS assignments from one server to another
[ https://issues.apache.org/jira/browse/TC-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-435: -- Assignee: Jeremy Mitchell > TPv2 - add the ability to clone DS assignments from one server to another > - > > Key: TC-435 > URL: https://issues.apache.org/jira/browse/TC-435 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > > Add the ability to clone DS assignments from one server to another. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-541) TPv2 - save the state of table filtering, ordering, etc
[ https://issues.apache.org/jira/browse/TC-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-541. Resolution: Fixed Fix Version/s: 2.2.0 > TPv2 - save the state of table filtering, ordering, etc > --- > > Key: TC-541 > URL: https://issues.apache.org/jira/browse/TC-541 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.2.0 > > > Currently for any of the tables in TPv2 lose their state (filtering, > ordering, etc) when you navigate away from them. This requires the user to > reenter the filter or reorder the table when they return to it which can be > quite time consuming. > Configure the tables to save their state. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-407) Cannot update a steering type delivery service via API
[
https://issues.apache.org/jira/browse/TC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16135719#comment-16135719
]
Jeremy Mitchell commented on TC-407:
I cannot reproduce this and I talked to [~jpappa200] and he thinks it was
resolved.
> Cannot update a steering type delivery service via API
> --
>
> Key: TC-407
> URL: https://issues.apache.org/jira/browse/TC-407
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0, 2.2.0
>Reporter: Joseph Pappano
>Assignee: Jeremy Mitchell
> Fix For: 2.1.0, 2.2.0
>
>
> The API to update a delivery service requires an origin server FQDN. Steering
> type delivery services to not have one and the api fails with the following
> error.
> {code}
> {u'alerts': [{u'level': u'error', u'text': u'orgServerFqdn is required'}]}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (TC-491) Deleting Delivery Service with associated job in job table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-491. Resolution: Fixed > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation > > > Key: TC-491 > URL: https://issues.apache.org/jira/browse/TC-491 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > Fix For: 2.1.0, 2.2.0 > > > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation. > E.g. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_job_deliveryservice1" on table "job" > DETAIL: Key (id)=(714) is still referenced from table "job". [for Statement > "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: 1='714'] at > /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: No UI/API end-point to delete the associated job. Delete > associated job from database. > NOTE: Other Traffic Ops versions may also be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-492) Deleting Delivery Service with associated static dns entry(s) in staticdnsentry table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-492. Resolution: Fixed > Deleting Delivery Service with associated static dns entry(s) in > staticdnsentry table fails due to foreign key constraint violation > --- > > Key: TC-492 > URL: https://issues.apache.org/jira/browse/TC-492 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0, 2.2.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > Fix For: 2.1.0, 2.2.0 > > > Deleting Delivery Service with associated static dns entry in staticdnsentry > table fails due to foreign key constraint violation. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_staticdnsentry_ds" on table "staticdnsentry" > DETAIL: Key (id)=(180) is still referenced from table "staticdnsentry". [for > Statement "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: > 1='180'] at /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: Use the UI to remove the association(s) before deleting the > delivery service. > NOTE: Other versions of Traffic Ops may be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-523) Assigning servers to Delivery services doesn't work in TP
[ https://issues.apache.org/jira/browse/TC-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-523: -- Assignee: Jeremy Mitchell > Assigning servers to Delivery services doesn't work in TP > - > > Key: TC-523 > URL: https://issues.apache.org/jira/browse/TC-523 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.2.0 >Reporter: David Neuman >Assignee: Jeremy Mitchell > Fix For: 2.2.0 > > > In Traffic Portal, if I create a new DS and try to assign servers to it, the > servers are not assigned to the DS. I don't get an error, but the servers are > not assigned. The workaround is to go to Traffic Ops and assign the servers > there. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-541) TPv2 - save the state of table filtering, ordering, etc
Jeremy Mitchell created TC-541: -- Summary: TPv2 - save the state of table filtering, ordering, etc Key: TC-541 URL: https://issues.apache.org/jira/browse/TC-541 Project: Traffic Control Issue Type: Improvement Components: Traffic Portal Reporter: Jeremy Mitchell Assignee: Jeremy Mitchell Priority: Minor Currently for any of the tables in TPv2 lose their state (filtering, ordering, etc) when you navigate away from them. This requires the user to reenter the filter or reorder the table when they return to it which can be quite time consuming. Configure the tables to save their state. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-441) TPv2 - implement password reset functionality
[ https://issues.apache.org/jira/browse/TC-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell updated TC-441: --- Affects Version/s: 2.1.0 Priority: Major (was: Minor) Issue Type: Bug (was: Improvement) > TPv2 - implement password reset functionality > - > > Key: TC-441 > URL: https://issues.apache.org/jira/browse/TC-441 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell > > implement password reset functionality -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-535) DS URL sig key apis needs to have tenancy check in place
Jeremy Mitchell created TC-535:
--
Summary: DS URL sig key apis needs to have tenancy check in place
Key: TC-535
URL: https://issues.apache.org/jira/browse/TC-535
Project: Traffic Control
Issue Type: Bug
Components: Traffic Ops API
Affects Versions: 2.1.0
Reporter: Jeremy Mitchell
Assignee: Nir Sopher
Tenancy was introduced in 2.1, however, by default it is turned off via the
use_tenancy parameter but when activated it is used to limit the scope of
delivery services that a user can act on.
The following APIs needs to check tenancy to ensure users cannot act on ds's
that they don't have access to.
post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/generate
post("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys/copyFromXmlId/:copyFromXmlId
get("/api/$version/deliveryservices/xmlId/:xmlId/urlkeys
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-533) GET /api/$version/deliveryservices/xmlId/#xmlid/sslkeys needs to have tenancy check in place
[
https://issues.apache.org/jira/browse/TC-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Mitchell updated TC-533:
---
Description:
Tenancy was introduced in 2.1, however, by default it is turned off via the
use_tenancy parameter but when activated it is used to limit the scope of
delivery services that a user can act on.
The following APIs needs to check tenancy to ensure users cannot act on ds's
that they don't have access to.
get("/api/$version/deliveryservices/xmlId/#xmlid/sslkeys
post("/api/$version/deliveryservices/sslkeys/generate
post("/api/$version/deliveryservices/sslkeys/add
get("/api/$version/deliveryservices/xmlId/:xmlid/sslkeys/delete
was:
Tenancy was introduced in 2.1, however, by default it is turned off via the
use_tenancy parameter but when activated it is used to limit the scope of
delivery services that a user can act on.
GET /api/$version/deliveryservices/xmlId/#xmlid/sslkeys needs to check tenancy
to ensure users cannot view ds info of ds's that they don't have access to.
> GET /api/$version/deliveryservices/xmlId/#xmlid/sslkeys needs to have tenancy
> check in place
>
>
> Key: TC-533
> URL: https://issues.apache.org/jira/browse/TC-533
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Nir Sopher
>
> Tenancy was introduced in 2.1, however, by default it is turned off via the
> use_tenancy parameter but when activated it is used to limit the scope of
> delivery services that a user can act on.
> The following APIs needs to check tenancy to ensure users cannot act on ds's
> that they don't have access to.
> get("/api/$version/deliveryservices/xmlId/#xmlid/sslkeys
> post("/api/$version/deliveryservices/sslkeys/generate
> post("/api/$version/deliveryservices/sslkeys/add
> get("/api/$version/deliveryservices/xmlId/:xmlid/sslkeys/delete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-533) DS SSL key apis needs to have tenancy check in place
[
https://issues.apache.org/jira/browse/TC-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Mitchell updated TC-533:
---
Summary: DS SSL key apis needs to have tenancy check in place (was: GET
/api/$version/deliveryservices/xmlId/#xmlid/sslkeys needs to have tenancy check
in place)
> DS SSL key apis needs to have tenancy check in place
>
>
> Key: TC-533
> URL: https://issues.apache.org/jira/browse/TC-533
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Jeremy Mitchell
>Assignee: Nir Sopher
>
> Tenancy was introduced in 2.1, however, by default it is turned off via the
> use_tenancy parameter but when activated it is used to limit the scope of
> delivery services that a user can act on.
> The following APIs needs to check tenancy to ensure users cannot act on ds's
> that they don't have access to.
> get("/api/$version/deliveryservices/xmlId/#xmlid/sslkeys
> post("/api/$version/deliveryservices/sslkeys/generate
> post("/api/$version/deliveryservices/sslkeys/add
> get("/api/$version/deliveryservices/xmlId/:xmlid/sslkeys/delete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-533) GET /api/$version/deliveryservices/xmlId/#xmlid/sslkeys needs to have tenancy check in place
Jeremy Mitchell created TC-533: -- Summary: GET /api/$version/deliveryservices/xmlId/#xmlid/sslkeys needs to have tenancy check in place Key: TC-533 URL: https://issues.apache.org/jira/browse/TC-533 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Affects Versions: 2.1.0 Reporter: Jeremy Mitchell Assignee: Nir Sopher Tenancy was introduced in 2.1, however, by default it is turned off via the use_tenancy parameter but when activated it is used to limit the scope of delivery services that a user can act on. GET /api/$version/deliveryservices/xmlId/#xmlid/sslkeys needs to check tenancy to ensure users cannot view ds info of ds's that they don't have access to. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-532) PUT /api/$version/deliveryservices/:id/safe needs to have tenancy check in place
Jeremy Mitchell created TC-532: -- Summary: PUT /api/$version/deliveryservices/:id/safe needs to have tenancy check in place Key: TC-532 URL: https://issues.apache.org/jira/browse/TC-532 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Affects Versions: 2.1.0 Reporter: Jeremy Mitchell Assignee: Dylan Volz Tenancy was introduced in 2.1, however, by default it is turned off via the use_tenancy parameter but when activated it is used to limit the scope of delivery services that a user can act on. PUT /api/$version/deliveryservices/:id/safe needs to check tenancy to ensure users do not attempt to update ds's that they don't have access to. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-492) Deleting Delivery Service with associated static dns entry(s) in staticdnsentry table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128816#comment-16128816 ] Jeremy Mitchell commented on TC-492: [~hbeatty] - yes, because of the priority, i think so. i'm working on it. > Deleting Delivery Service with associated static dns entry(s) in > staticdnsentry table fails due to foreign key constraint violation > --- > > Key: TC-492 > URL: https://issues.apache.org/jira/browse/TC-492 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > > Deleting Delivery Service with associated static dns entry in staticdnsentry > table fails due to foreign key constraint violation. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_staticdnsentry_ds" on table "staticdnsentry" > DETAIL: Key (id)=(180) is still referenced from table "staticdnsentry". [for > Statement "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: > 1='180'] at /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: Use the UI to remove the association(s) before deleting the > delivery service. > NOTE: Other versions of Traffic Ops may be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-516) Deleting a DS thru the API should also delete all SSL keys (if applicable)
[ https://issues.apache.org/jira/browse/TC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128812#comment-16128812 ] Jeremy Mitchell commented on TC-516: [~hbeatty] - yes, this should be resolved for 2.1. I'll try to get to it but maybe/hopefully somebody else can pick it up. Maybe you should share the list of Major+ bugs for 2.1 to see if we can get any volunteers. > Deleting a DS thru the API should also delete all SSL keys (if applicable) > -- > > Key: TC-516 > URL: https://issues.apache.org/jira/browse/TC-516 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell > > There are currently 4 protocols for a DS: > 0 - HTTP > 1 - HTTPS > 2 - HTTP AND HTTPS > 3 - HTTP TO HTTPS > Currently, if you delete a DS thru the API, SSL keys are not deleted. This > should occur if ds.protocol > 0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-500) Creating/Updating a Delivery Service via API has length constraint on displayName of 48, but no such constraint in UI code
[ https://issues.apache.org/jira/browse/TC-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128810#comment-16128810 ] Jeremy Mitchell commented on TC-500: [~hbeatty]- the priority was reduced so i think 2.2 is fine > Creating/Updating a Delivery Service via API has length constraint on > displayName of 48, but no such constraint in UI code > -- > > Key: TC-500 > URL: https://issues.apache.org/jira/browse/TC-500 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Robert Scrimo >Priority: Minor > > Creating/Updating a Delivery Service via API code has length constraint on > `displayName` of 48, but there is no such constraint in the UI code so any > user can update the value to more than 48 characters. The Database field is > Text which is described as "variable unlimited length" in the Postgres > documentation. However, the value may be limited by the GUI field if such a > constraint exists. > NOTE: The GET methods for /api/1.2/deliveryservices does not check the > length on the `displayName` field, so, it will return whatever is in the > database for `displayName`. > Work Around: Upon getting the Delivery Service information from the API, in > order to update/create the Delivery Service via the API you will need to > limit the number of characters in the `displayName` to 48. > NOTE: Other versions of Traffic Ops may be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-491) Deleting Delivery Service with associated job in job table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128807#comment-16128807 ] Jeremy Mitchell commented on TC-491: [~hbeatty] - yes, it should be fixed. i'm working on it. > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation > > > Key: TC-491 > URL: https://issues.apache.org/jira/browse/TC-491 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation. > E.g. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_job_deliveryservice1" on table "job" > DETAIL: Key (id)=(714) is still referenced from table "job". [for Statement > "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: 1='714'] at > /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: No UI/API end-point to delete the associated job. Delete > associated job from database. > NOTE: Other Traffic Ops versions may also be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-80) Add api/version/cachegroups/:id/parameters endpoint
[ https://issues.apache.org/jira/browse/TC-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell closed TC-80. - > Add api/version/cachegroups/:id/parameters endpoint > --- > > Key: TC-80 > URL: https://issues.apache.org/jira/browse/TC-80 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 1.9.0 > > > Provide the ability to fetch cachegroup parameters through the api such as > api/version/cachegroups/:id/parameters > Also, while you're in there, provide the ability to fetch cachegroup asns > through the api such as: > api/version/asns?cachegroup=x > and filter phys locations by region like: > api/version/physLocations?region=x -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-64) Experimental SPA application
[ https://issues.apache.org/jira/browse/TC-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell closed TC-64. - > Experimental SPA application > > > Key: TC-64 > URL: https://issues.apache.org/jira/browse/TC-64 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops, Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Labels: spa > > At the 2016 Traffic Control summit, a prototype of a SPA application > developed by [~mitchell...@apache.org] using AngularJS was demo'd that works > entirely on top of the TO API. > This issue is a placeholder for any work done to this prototype / > experimental UI. The goal is to replicate the functionality of the current > MVC TO UI. nothing more, nothing less. > This will require some additions to the TO API. look for issues regarding > each API addition. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-64) Experimental SPA application
[ https://issues.apache.org/jira/browse/TC-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-64. --- Resolution: Fixed > Experimental SPA application > > > Key: TC-64 > URL: https://issues.apache.org/jira/browse/TC-64 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops, Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Labels: spa > > At the 2016 Traffic Control summit, a prototype of a SPA application > developed by [~mitchell...@apache.org] using AngularJS was demo'd that works > entirely on top of the TO API. > This issue is a placeholder for any work done to this prototype / > experimental UI. The goal is to replicate the functionality of the current > MVC TO UI. nothing more, nothing less. > This will require some additions to the TO API. look for issues regarding > each API addition. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-60) CDN usage overview API always returns tps=0
[ https://issues.apache.org/jira/browse/TC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128261#comment-16128261 ] Jeremy Mitchell commented on TC-60: --- [~hbeatty] - no need to fix in 2.1 > CDN usage overview API always returns tps=0 > --- > > Key: TC-60 > URL: https://issues.apache.org/jira/browse/TC-60 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 1.7.0 >Reporter: Jeremy Mitchell >Priority: Minor > Labels: api_usage > > /api/1.2/cdns/usage/overview always returns tps=0 > I suspect the problem lies in the usage_overview_tps_query() query > https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/Extensions/TrafficStats/Delegate/CdnStatistics.pm#L104 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-71) Remove hardcoded reference to ccr in UI/DeliveryService.pm
[ https://issues.apache.org/jira/browse/TC-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-71: - Assignee: Jeremy Mitchell > Remove hardcoded reference to ccr in UI/DeliveryService.pm > -- > > Key: TC-71 > URL: https://issues.apache.org/jira/browse/TC-71 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Labels: deliveryservice.pm, routing > > because the value of http.routing.name in applicationContext.xml can be > anything (defaults to tr), this needs to be dynamic rather than referencing > the hard-coded value of 'ccr'. So my suggestion would be: > create a global parameter using a database migration file and name the > parameter http.routing.name and set the default value to 'tr'. then in the > code, fetch the value of http.routing.name and use that on line 147 & 150 > https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/UI/DeliveryService.pm#L147 > https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/UI/DeliveryService.pm#L150 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-82) Eliminate duplicate implementations of deliveryservice, cachegroup and server api endpoints
[ https://issues.apache.org/jira/browse/TC-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell closed TC-82. - > Eliminate duplicate implementations of deliveryservice, cachegroup and server > api endpoints > --- > > Key: TC-82 > URL: https://issues.apache.org/jira/browse/TC-82 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Labels: api_endpoints > > The following endpoints are duplicates and need to be reconciled: > Delivery Services: > GET /api/$version/deliveryservices > GET /api/$version/deliveryservices/list <-- remove > GET /api/$version/deliveryservices/:id > GET /api/$version/deliveryservices/:id/get <-- remove > POST /api/$version/deliveryservices > POST /api/$version/deliveryservices/create <-- remove > PUT /api/$version/deliveryservices/:id > PUT /api/$version/deliveryservices/:id/update <-- remove > Cache Groups: > GET /api/$version/cachegroups > GET /api/$version/cachegroups/list <-- remove > POST /api/$version/cachegroups > POST /api/$version/cachegroups/create <-- remove > PUT /api/$version/cachegroups/:id > PUT /api/$version/cachegroups/:id/update <-- remove > DELETE /api/$version/cachegroups/:id > DELETE /api/$version/cachegroups/:id/delete <-- remove > Servers: > POST /api/$version/servers > POST /api/$version/servers/create <-- remove > PUT /api/$version/servers/:id > PUT /api/$version/servers/:id/update <-- remove -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-71) Remove hardcoded reference to ccr in UI/DeliveryService.pm
[ https://issues.apache.org/jira/browse/TC-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-71: - Assignee: Rawlin Peters (was: Jeremy Mitchell) > Remove hardcoded reference to ccr in UI/DeliveryService.pm > -- > > Key: TC-71 > URL: https://issues.apache.org/jira/browse/TC-71 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Jeremy Mitchell >Assignee: Rawlin Peters >Priority: Minor > Labels: deliveryservice.pm, routing > > because the value of http.routing.name in applicationContext.xml can be > anything (defaults to tr), this needs to be dynamic rather than referencing > the hard-coded value of 'ccr'. So my suggestion would be: > create a global parameter using a database migration file and name the > parameter http.routing.name and set the default value to 'tr'. then in the > code, fetch the value of http.routing.name and use that on line 147 & 150 > https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/UI/DeliveryService.pm#L147 > https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/UI/DeliveryService.pm#L150 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-81) Add additional filters to collection apis
[ https://issues.apache.org/jira/browse/TC-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell closed TC-81. - > Add additional filters to collection apis > - > > Key: TC-81 > URL: https://issues.apache.org/jira/browse/TC-81 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 1.9.0 > > > Add the ability to filter the following collections as follows: > /api/deliveryservices/:id/servers <-- retrieve all edge servers assigned to a > ds > /api/servers/:id/deliveryservices <-- retrieve all ds's assigend to a server > /api/parameters/:id/profiles <-- retrieve all profiles assigned to a parameter > /api/users/:id/deliveryservices <-- retrieve all ds's assigned to a user > /api/deliveryservices?cdn=x <-- to retrieve a cdn's ds's > /api/regions?division=x <-- to retrieve a division's regions > /api/servers?physLocation=x <-- to retrieve a phys location's servers > /api/cachegroups?type=x <-- to retrieve cachegroups by type > /api/deliveryservices?type=x <-- to retrieve deliveryservices by type > The api already provides the ability to: > - retrieve a cachegroup's asns > - retrieve a cachegroup's parameters > - retrieve a cachegroup's servers > - retrieve a cdn's servers > - retrieve a profile's parameters > - retrieve a profile's servers > - retrieve a region's phys locations > By adding these additional filters, it provides the ability to navigate the > relationships in the database (i.e. provides drill-down capabilities) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-100) DELETE api/version/regions/:id should ensure no phys locs are in the region
[ https://issues.apache.org/jira/browse/TC-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128257#comment-16128257 ] Jeremy Mitchell commented on TC-100: no need to fix in 2.1 [~hbeatty] > DELETE api/version/regions/:id should ensure no phys locs are in the region > --- > > Key: TC-100 > URL: https://issues.apache.org/jira/browse/TC-100 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Reporter: Jeremy Mitchell >Priority: Minor > Labels: api_regions > > Currently, you can attempt to delete a region that is employed by a phys > location which results in a database FK constraint error. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table region violates foreign > key constraint fk_phys_location_region on table > phys_location > DETAIL: Key (id)=(1) is still referenced from table > phys_location. [for Statement DELETE FROM region WHERE ( id > = ? ) with ParamValues: 1=1] at > /opt/traffic_ops/app/lib/API/Region.pm line 243 > the api needs to ensure that no phys locs use the region before attempting to > delete the region. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-82) Eliminate duplicate implementations of deliveryservice, cachegroup and server api endpoints
[ https://issues.apache.org/jira/browse/TC-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-82. --- Resolution: Fixed > Eliminate duplicate implementations of deliveryservice, cachegroup and server > api endpoints > --- > > Key: TC-82 > URL: https://issues.apache.org/jira/browse/TC-82 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Labels: api_endpoints > > The following endpoints are duplicates and need to be reconciled: > Delivery Services: > GET /api/$version/deliveryservices > GET /api/$version/deliveryservices/list <-- remove > GET /api/$version/deliveryservices/:id > GET /api/$version/deliveryservices/:id/get <-- remove > POST /api/$version/deliveryservices > POST /api/$version/deliveryservices/create <-- remove > PUT /api/$version/deliveryservices/:id > PUT /api/$version/deliveryservices/:id/update <-- remove > Cache Groups: > GET /api/$version/cachegroups > GET /api/$version/cachegroups/list <-- remove > POST /api/$version/cachegroups > POST /api/$version/cachegroups/create <-- remove > PUT /api/$version/cachegroups/:id > PUT /api/$version/cachegroups/:id/update <-- remove > DELETE /api/$version/cachegroups/:id > DELETE /api/$version/cachegroups/:id/delete <-- remove > Servers: > POST /api/$version/servers > POST /api/$version/servers/create <-- remove > PUT /api/$version/servers/:id > PUT /api/$version/servers/:id/update <-- remove -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-102) API changes to reflect true datatypes
[ https://issues.apache.org/jira/browse/TC-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell closed TC-102. -- > API changes to reflect true datatypes > - > > Key: TC-102 > URL: https://issues.apache.org/jira/browse/TC-102 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops, Traffic Ops API >Affects Versions: 2.0.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell > Labels: postgres > Fix For: 2.0.0 > > > With the move from MySQL to Postgres, the API will reflect the true data > types of each value as represented in the database. For example, the Postgres > version of the TO database now has boolean columns (rather than using > smallint). These values should be represented in the API as booleans > (true|false) as opposed to "0"|"1" as before. > Also, in the old MySQL TO, ints or numbers were represented as "age":"23" in > the API. That should change to "age":23 > These are the datatypes available in json and they should be taken advantage > of when possible: > Boolean: true|false > String: double-quoted Unicode with backslash escaping > Number: double- precision floating-point format > Array: an ordered sequence of values > Object: an unordered collection of key:value pairs > Null > I'm creating this issue as a catch-all for any changes required to reflect > the true data types in the api. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-123) UI route (/healthdatadeliveryservice) is broken as no related html template exists
[ https://issues.apache.org/jira/browse/TC-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128250#comment-16128250 ] Jeremy Mitchell commented on TC-123: no need to fix in 2.1 [~hbeatty] > UI route (/healthdatadeliveryservice) is broken as no related html template > exists > -- > > Key: TC-123 > URL: https://issues.apache.org/jira/browse/TC-123 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops API >Affects Versions: 2.1.0, 2.0.0 >Reporter: Jeremy Mitchell >Priority: Trivial > Labels: api_healthdatadeliveryservice > > /healthdatadeliveryservice returns a 404 as no related html template exists > for this route. My guess is this route can be deleted entirely but some > research is probably needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-123) UI route (/healthdatadeliveryservice) is broken as no related html template exists
[ https://issues.apache.org/jira/browse/TC-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell updated TC-123: --- Priority: Trivial (was: Minor) > UI route (/healthdatadeliveryservice) is broken as no related html template > exists > -- > > Key: TC-123 > URL: https://issues.apache.org/jira/browse/TC-123 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops API >Affects Versions: 2.1.0, 2.0.0 >Reporter: Jeremy Mitchell >Priority: Trivial > Labels: api_healthdatadeliveryservice > > /healthdatadeliveryservice returns a 404 as no related html template exists > for this route. My guess is this route can be deleted entirely but some > research is probably needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-149) GET api/1.2/deliveryservices/hostname/:hostname/sslkeys returns 400
[ https://issues.apache.org/jira/browse/TC-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell closed TC-149. -- Resolution: Cannot Reproduce > GET api/1.2/deliveryservices/hostname/:hostname/sslkeys returns 400 > --- > > Key: TC-149 > URL: https://issues.apache.org/jira/browse/TC-149 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops API >Reporter: Jeremy Mitchell >Priority: Minor > Labels: api_deliveryservices > > GET api/1.2/deliveryservices/hostname/:hostname/sslkeys returns 400 even > though it can reach the Riak servers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-191) Steering DS API should use standard response codes as defined in API guidelines
[ https://issues.apache.org/jira/browse/TC-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-191: -- Assignee: (was: Jeremy Mitchell) > Steering DS API should use standard response codes as defined in API > guidelines > --- > > Key: TC-191 > URL: https://issues.apache.org/jira/browse/TC-191 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell >Priority: Minor > Labels: steering > Fix For: 2.2.0 > > > To keep the API consistent, API guidelines have been documented here: > https://cwiki.apache.org/confluence/display/TC/API+Guidelines > See "Response Codes" section. Also, there are helper functions in > Utils/Helper.pm to return error response codes along with a message. > By keeping response codes consistent, it makes it easier to consume the api > and respond to error scenarios. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-308) hdr_rw_* gets inserted in profiles, but they don't get removed...
[
https://issues.apache.org/jira/browse/TC-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Mitchell updated TC-308:
---
Reporter: Steve Malenfant (was: Jeremy Mitchell)
> hdr_rw_* gets inserted in profiles, but they don't get removed...
> -
>
> Key: TC-308
> URL: https://issues.apache.org/jira/browse/TC-308
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Reporter: Steve Malenfant
>Priority: Minor
> Labels: profile_parameters
>
> Moved from https://github.com/Comcast/traffic_control/issues/714
> Spend lots of time troubleshooting an config file generation issue which
> referred to a delivery service that was deleted or renamed.
> If you look at the Profile Parameters, you'll notice there is entries you
> probably never created yourselves. During configuration file generation,
> looks like it looks for "^hdr_rw_mid" to see if needs to generate a file.
> If the parameter still exists and the delivery service doesn't, it throws an
> error on either line 1210 or 1216 (looks like edge_header_rewrite is causing
> a problem too).
> Removing the parameter does fix the problem. Do we really need to insert
> those "locations" in the database?
> sub header_rewrite_dot_config {
> my $self = shift;
> my $id = shift;
> my $file = shift;
> my $server= $self->server_data($id);
> my $text = $self->header_comment( $server->host_name );
> my $ds_xml_id = undef;
> if ( $file =~ /^hdr_rw_mid_(.*)\.config$/ ) {
> $ds_xml_id = $1;
> my $ds = $self->db->resultset('Deliveryservice')->search( { xml_id =>
> $ds_xml_id }, { prefetch => [ 'type', 'profile' ] } )->single();
> my $actions = $ds->mid_header_rewrite;
> $text .= $actions . "\n";
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (TC-423) TPv2 - add the ability to copy profiles
[ https://issues.apache.org/jira/browse/TC-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-423. Resolution: Fixed Fix Version/s: 2.1.0 > TPv2 - add the ability to copy profiles > --- > > Key: TC-423 > URL: https://issues.apache.org/jira/browse/TC-423 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.1.0 > > > In order to achieve feature parity with the existing TO UI, the ability to > copy profiles needs to be added to TP. This involves making a new profile > where you can define the name, description, cdn and type of the profile but > use the parameters of an existing profile. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-419) TPv2 - enable auto-refresh for dashboard widgets
[
https://issues.apache.org/jira/browse/TC-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Mitchell updated TC-419:
---
Fix Version/s: 2.1.0
> TPv2 - enable auto-refresh for dashboard widgets
>
>
> Key: TC-419
> URL: https://issues.apache.org/jira/browse/TC-419
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Portal
>Reporter: Jeremy Mitchell
>Assignee: Jeremy Mitchell
>Priority: Minor
> Fix For: 2.1.0
>
>
> The widgets found on the Traffic Portal dashboard -
> http://localhost:8080/#!/monitor/dashboard - should be set to auto-refresh at
> a defined interval. This refresh should be configurable. I.e.
> dashboard: {
> refresh: {
> enabled: true|false,
> interval: 3
> }
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (TC-437) TPv2 - add the ability to generate ISO
[ https://issues.apache.org/jira/browse/TC-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-437. Resolution: Fixed Fix Version/s: 2.1.0 > TPv2 - add the ability to generate ISO > -- > > Key: TC-437 > URL: https://issues.apache.org/jira/browse/TC-437 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.1.0 > > > add the ability to generate ISO -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-423) TPv2 - add the ability to copy profiles
[ https://issues.apache.org/jira/browse/TC-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-423: -- Assignee: Jeremy Mitchell > TPv2 - add the ability to copy profiles > --- > > Key: TC-423 > URL: https://issues.apache.org/jira/browse/TC-423 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > > In order to achieve feature parity with the existing TO UI, the ability to > copy profiles needs to be added to TP. This involves making a new profile > where you can define the name, description, cdn and type of the profile but > use the parameters of an existing profile. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-433) TPv2 - Add the ability to manage SSL keys for a delivery service
[ https://issues.apache.org/jira/browse/TC-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-433: -- Assignee: Dylan Volz > TPv2 - Add the ability to manage SSL keys for a delivery service > > > Key: TC-433 > URL: https://issues.apache.org/jira/browse/TC-433 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Dylan Volz >Priority: Minor > > Add the ability to manage SSL keys for a delivery service -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-437) TPv2 - add the ability to generate ISO
[ https://issues.apache.org/jira/browse/TC-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-437: -- Assignee: Jeremy Mitchell > TPv2 - add the ability to generate ISO > -- > > Key: TC-437 > URL: https://issues.apache.org/jira/browse/TC-437 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > > add the ability to generate ISO -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-441) TPv2 - implement password reset functionality
[ https://issues.apache.org/jira/browse/TC-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-441: -- Assignee: Jeremy Mitchell > TPv2 - implement password reset functionality > - > > Key: TC-441 > URL: https://issues.apache.org/jira/browse/TC-441 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > > implement password reset functionality -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-453) TO API - change log entry not created when queuing updates on a cachegroup
[ https://issues.apache.org/jira/browse/TC-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-453. Resolution: Fixed > TO API - change log entry not created when queuing updates on a cachegroup > -- > > Key: TC-453 > URL: https://issues.apache.org/jira/browse/TC-453 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.1.0 > > > a change log entry should be created when queuing updates on a cache group. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (TC-480) TPv2 - show example URLs for delivery service
[ https://issues.apache.org/jira/browse/TC-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reopened TC-480: Assignee: Jeremy Mitchell > TPv2 - show example URLs for delivery service > - > > Key: TC-480 > URL: https://issues.apache.org/jira/browse/TC-480 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.1.0 > > > On the deliveryservice view/edit page, show exampleUrls which should be > returned from the GET /api/*/deliveryservices/:id api -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-480) TPv2 - show example URLs for delivery service
[ https://issues.apache.org/jira/browse/TC-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-480. Resolution: Fixed > TPv2 - show example URLs for delivery service > - > > Key: TC-480 > URL: https://issues.apache.org/jira/browse/TC-480 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.1.0 > > > On the deliveryservice view/edit page, show exampleUrls which should be > returned from the GET /api/*/deliveryservices/:id api -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-486) Add steering role to steering apis
[ https://issues.apache.org/jira/browse/TC-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-486. Resolution: Fixed > Add steering role to steering apis > -- > > Key: TC-486 > URL: https://issues.apache.org/jira/browse/TC-486 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.1.0 > > > Create, update and delete of steering targets should be available to users > with the "steering" role. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-498) TO API - when updating current user, full name is required
[ https://issues.apache.org/jira/browse/TC-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-498. Resolution: Fixed Fix Version/s: 2.1.0 > TO API - when updating current user, full name is required > -- > > Key: TC-498 > URL: https://issues.apache.org/jira/browse/TC-498 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.1.0 > > > case error caused validation to fail. see fullName vs full_name > https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/User.pm#L646 > https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/User.pm#L653 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (TC-486) Add steering role to steering apis
[ https://issues.apache.org/jira/browse/TC-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reopened TC-486: > Add steering role to steering apis > -- > > Key: TC-486 > URL: https://issues.apache.org/jira/browse/TC-486 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.1.0 > > > Create, update and delete of steering targets should be available to users > with the "steering" role. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-524) TP - popout button on TPv2 doesn't open new window/tab as intended
[ https://issues.apache.org/jira/browse/TC-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-524. Resolution: Fixed > TP - popout button on TPv2 doesn't open new window/tab as intended > -- > > Key: TC-524 > URL: https://issues.apache.org/jira/browse/TC-524 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (TC-524) TP - popout button on TPv2 doesn't open new window/tab as intended
[ https://issues.apache.org/jira/browse/TC-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reopened TC-524: > TP - popout button on TPv2 doesn't open new window/tab as intended > -- > > Key: TC-524 > URL: https://issues.apache.org/jira/browse/TC-524 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-524) TP - popout button on TPv2 doesn't open new window/tab as intended
[ https://issues.apache.org/jira/browse/TC-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell closed TC-524. -- > TP - popout button on TPv2 doesn't open new window/tab as intended > -- > > Key: TC-524 > URL: https://issues.apache.org/jira/browse/TC-524 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-524) TP - popout button on TPv2 doesn't open new window/tab as intended
[ https://issues.apache.org/jira/browse/TC-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-524. Resolution: Fixed Fix Version/s: 2.2.0 > TP - popout button on TPv2 doesn't open new window/tab as intended > -- > > Key: TC-524 > URL: https://issues.apache.org/jira/browse/TC-524 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-524) TP - popout button on TPv2 doesn't open new window/tab as intended
Jeremy Mitchell created TC-524: -- Summary: TP - popout button on TPv2 doesn't open new window/tab as intended Key: TC-524 URL: https://issues.apache.org/jira/browse/TC-524 Project: Traffic Control Issue Type: Bug Components: Traffic Portal Reporter: Jeremy Mitchell Assignee: Jeremy Mitchell Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TC-522) "Online Caches" on TP Dashboard is confusing
[ https://issues.apache.org/jira/browse/TC-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127567#comment-16127567 ] Jeremy Mitchell edited comment on TC-522 at 8/15/17 5:36 PM: - My intent with the top bar of the dashboard page of TP was to show the count of caches grouped by status or health. Not to display the statuses of "other servers" (TR, TM, TP, etc, etc) !dashboard-cache-statuses.png! So rather than changing the label to "Online Servers" which will mix things, I'd rather remove "Online Caches" altogether from the dashboard OR filter the api respone so it really shows the count of servers where type=EDGE|MID (caches) and status=ONLINE (which as you said should always be zero) from my understanding from [~elsloo] the ONLINE status can be used to force caches online (no monitoring. maybe monitoring is not possible for some reason. firewalls, etc.) but maybe like you said it should never be used for caches or used with caution so maybe having this count at the top is a good thing to ensure the number stays at zero?? ... or if really, truly, caches should never be set to ONLINE, the api should be modified to prevent it. was (Author: mitchell...@apache.org): My intent with the top bar of the dashboard page of TP was to show the count of caches grouped by status or health. Not to display the statuses of "other servers" (TR, TM, TP, etc, etc) !dashboard-cache-statuses.png! So rather than changing the label to "Online Servers" which will mix things, I'd rather remove "Online Caches" altogether from the dashboard OR filter the api respone so it really shows the count of servers where type=EDGE|MID (caches) and status=ONLINE (which as you said should always be zero) from my understanding from [~elsloo] the ONLINE status can be used to force caches online (no monitoring. maybe monitoring is not possible for some reason. firewalls, etc.) but maybe like you said it should never be used for caches or used with caution so maybe having this count at the top is a good thing to ensure the number stays at zero... ... or if really, truly, caches should never be set to ONLINE, the api should be modified to prevent it. > "Online Caches" on TP Dashboard is confusing > > > Key: TC-522 > URL: https://issues.apache.org/jira/browse/TC-522 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.2.0 >Reporter: David Neuman >Priority: Minor > Attachments: dashboard-cache-statuses.png > > > The dashboard page of traffic portal shows Reported Caches, Healthy Caches, > Unhealthy Caches, Online Caches, Offline Caches, etc. This is nice to have > and definitely useful but "online caches" is a little mis-leading. Under > normal circumstances, caches shouldn't be in an online state. They should > only be in Reported, Admin-Down, or Offline states. This is because if they > are online, TM will not monitor them, but TR will route to them. If TR is > routing to caches that are not being monitored, we could be routing to caches > with issues. > Usually support servers are the only servers that are in an online state. > We should either change the wording on the portal to be "Online Servers" or > remove the online caches stat all together. My vote is to change the wording. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-522) "Online Caches" on TP Dashboard is confusing
[ https://issues.apache.org/jira/browse/TC-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127576#comment-16127576 ] Jeremy Mitchell commented on TC-522: Also, "Offline Caches" is misleading because this is really a count of "Offline Servers" so the API really needs to be filtered to only include type=EDGE|MID > "Online Caches" on TP Dashboard is confusing > > > Key: TC-522 > URL: https://issues.apache.org/jira/browse/TC-522 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.2.0 >Reporter: David Neuman >Priority: Minor > Attachments: dashboard-cache-statuses.png > > > The dashboard page of traffic portal shows Reported Caches, Healthy Caches, > Unhealthy Caches, Online Caches, Offline Caches, etc. This is nice to have > and definitely useful but "online caches" is a little mis-leading. Under > normal circumstances, caches shouldn't be in an online state. They should > only be in Reported, Admin-Down, or Offline states. This is because if they > are online, TM will not monitor them, but TR will route to them. If TR is > routing to caches that are not being monitored, we could be routing to caches > with issues. > Usually support servers are the only servers that are in an online state. > We should either change the wording on the portal to be "Online Servers" or > remove the online caches stat all together. My vote is to change the wording. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TC-522) "Online Caches" on TP Dashboard is confusing
[ https://issues.apache.org/jira/browse/TC-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127567#comment-16127567 ] Jeremy Mitchell edited comment on TC-522 at 8/15/17 5:22 PM: - My intent with the top bar of the dashboard page of TP was to show the count of caches grouped by status or health. Not to display the statuses of "other servers" (TR, TM, TP, etc, etc) !dashboard-cache-statuses.png! So rather than changing the label to "Online Servers" which will mix things, I'd rather remove "Online Caches" altogether from the dashboard OR filter the api respone so it really shows the count of servers where type=EDGE|MID and status=ONLINE (which as you said should always be zero) from my understanding from [~elsloo] the ONLINE status can be used to force caches online (no monitoring. maybe monitoring is not possible for some reason. firewalls, etc.) but maybe like you said it should never be used for caches or used with caution so maybe having this count at the top is a good thing to ensure the number stays at zero... ... or if really, truly, caches should never be set to ONLINE, the api should be modified to prevent it. was (Author: mitchell...@apache.org): My intent with the top bar of the dashboard page of TP was to show the count of caches grouped by status or health. Not to display the statuses of "other servers" (TR, TM, TP, etc, etc) !dashboard-cache-statuses.png! So rather than changing the label to "Online Servers" which will mix things, I'd rather remove "Online Caches" altogether from the dashboard OR filter the api respone so it really shows the count of servers where type=EDGE|MID and status=ONLINE (which as you said should always be zero) from my understanding from [~elsloo] the ONLINE status can be used to force caches online (no monitoring) but maybe like you said it should never be used for caches or used with caution so maybe having this count at the top is a good thing to ensure the number stays at zero... ... or if really, truly, caches should never be set to ONLINE, the api should be modified to prevent it. > "Online Caches" on TP Dashboard is confusing > > > Key: TC-522 > URL: https://issues.apache.org/jira/browse/TC-522 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.2.0 >Reporter: David Neuman >Priority: Minor > Attachments: dashboard-cache-statuses.png > > > The dashboard page of traffic portal shows Reported Caches, Healthy Caches, > Unhealthy Caches, Online Caches, Offline Caches, etc. This is nice to have > and definitely useful but "online caches" is a little mis-leading. Under > normal circumstances, caches shouldn't be in an online state. They should > only be in Reported, Admin-Down, or Offline states. This is because if they > are online, TM will not monitor them, but TR will route to them. If TR is > routing to caches that are not being monitored, we could be routing to caches > with issues. > Usually support servers are the only servers that are in an online state. > We should either change the wording on the portal to be "Online Servers" or > remove the online caches stat all together. My vote is to change the wording. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-522) "Online Caches" on TP Dashboard is confusing
[ https://issues.apache.org/jira/browse/TC-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127567#comment-16127567 ] Jeremy Mitchell commented on TC-522: My intent with the top bar of the dashboard page of TP was to show the count of caches grouped by status or health. Not to display the statuses of "other servers" (TR, TM, TP, etc, etc) !dashboard-cache-statuses.png! So rather than changing the label to "Online Servers" which will mix things, I'd rather remove "Online Caches" altogether from the dashboard OR filter the api respone so it really shows the count of servers where type=EDGE|MID and status=ONLINE (which as you said should always be zero) from my understanding from [~elsloo] the ONLINE status can be used to force caches online (no monitoring) but maybe like you said it should never be used for caches or used with caution so maybe having this count at the top is a good thing to ensure the number stays at zero... ... or if really, truly, caches should never be set to ONLINE, the api should be modified to prevent it. > "Online Caches" on TP Dashboard is confusing > > > Key: TC-522 > URL: https://issues.apache.org/jira/browse/TC-522 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.2.0 >Reporter: David Neuman >Priority: Minor > Attachments: dashboard-cache-statuses.png > > > The dashboard page of traffic portal shows Reported Caches, Healthy Caches, > Unhealthy Caches, Online Caches, Offline Caches, etc. This is nice to have > and definitely useful but "online caches" is a little mis-leading. Under > normal circumstances, caches shouldn't be in an online state. They should > only be in Reported, Admin-Down, or Offline states. This is because if they > are online, TM will not monitor them, but TR will route to them. If TR is > routing to caches that are not being monitored, we could be routing to caches > with issues. > Usually support servers are the only servers that are in an online state. > We should either change the wording on the portal to be "Online Servers" or > remove the online caches stat all together. My vote is to change the wording. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-522) "Online Caches" on TP Dashboard is confusing
[ https://issues.apache.org/jira/browse/TC-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell updated TC-522: --- Attachment: dashboard-cache-statuses.png > "Online Caches" on TP Dashboard is confusing > > > Key: TC-522 > URL: https://issues.apache.org/jira/browse/TC-522 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.2.0 >Reporter: David Neuman >Priority: Minor > Attachments: dashboard-cache-statuses.png > > > The dashboard page of traffic portal shows Reported Caches, Healthy Caches, > Unhealthy Caches, Online Caches, Offline Caches, etc. This is nice to have > and definitely useful but "online caches" is a little mis-leading. Under > normal circumstances, caches shouldn't be in an online state. They should > only be in Reported, Admin-Down, or Offline states. This is because if they > are online, TM will not monitor them, but TR will route to them. If TR is > routing to caches that are not being monitored, we could be routing to caches > with issues. > Usually support servers are the only servers that are in an online state. > We should either change the wording on the portal to be "Online Servers" or > remove the online caches stat all together. My vote is to change the wording. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-521) TPv2 - http-parser dependency cannot be resolved
Jeremy Mitchell created TC-521: -- Summary: TPv2 - http-parser dependency cannot be resolved Key: TC-521 URL: https://issues.apache.org/jira/browse/TC-521 Project: Traffic Control Issue Type: Bug Components: Traffic Portal Affects Versions: 2.1.0 Reporter: Jeremy Mitchell Assignee: Jeremy Mitchell Priority: Blocker Fix For: 2.1.0 Therefore the Traffic Portal build fails. More details of the error: https://bugs.centos.org/view.php?id=13669=1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-520) TPv2 - add the ability to see all delivery services for each tenant
Jeremy Mitchell created TC-520: -- Summary: TPv2 - add the ability to see all delivery services for each tenant Key: TC-520 URL: https://issues.apache.org/jira/browse/TC-520 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops API, Traffic Portal Reporter: Jeremy Mitchell Assignee: Jeremy Mitchell Priority: Minor Delivery services are grouped by tenant. Add the ability to see all ds's for each tenant. This will help tenancy management. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-517) TPv2 - add the ability to see all users for each tenant
[ https://issues.apache.org/jira/browse/TC-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-517: -- Assignee: Jeremy Mitchell > TPv2 - add the ability to see all users for each tenant > --- > > Key: TC-517 > URL: https://issues.apache.org/jira/browse/TC-517 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > > Users are grouped by tenant. Add the ability to see all users for each > tenant. This will help user management significantly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-519) TP - tenants menu item mistakenly removed from TP
Jeremy Mitchell created TC-519: -- Summary: TP - tenants menu item mistakenly removed from TP Key: TC-519 URL: https://issues.apache.org/jira/browse/TC-519 Project: Traffic Control Issue Type: Bug Components: Traffic Portal Affects Versions: 2.1.0 Reporter: Jeremy Mitchell Assignee: Jeremy Mitchell Fix For: 2.1.0 Somehow the tenants menu was mistakenly removed from TP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-434) TPv2 - add the ability to manage URL sig keys
[ https://issues.apache.org/jira/browse/TC-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell closed TC-434. -- Resolution: Duplicate duplicate of tc-336 > TPv2 - add the ability to manage URL sig keys > - > > Key: TC-434 > URL: https://issues.apache.org/jira/browse/TC-434 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API, Traffic Portal >Reporter: Jeremy Mitchell >Priority: Minor > > Add the ability to manage URL sig keys -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-517) TPv2 - add the ability to see all users for each tenant
Jeremy Mitchell created TC-517: -- Summary: TPv2 - add the ability to see all users for each tenant Key: TC-517 URL: https://issues.apache.org/jira/browse/TC-517 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops API, Traffic Portal Reporter: Jeremy Mitchell Priority: Minor Users are grouped by tenant. Add the ability to see all users for each tenant. This will help user management significantly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-516) Deleting a DS thru the API should also delete all SSL keys (if applicable)
Jeremy Mitchell created TC-516: -- Summary: Deleting a DS thru the API should also delete all SSL keys (if applicable) Key: TC-516 URL: https://issues.apache.org/jira/browse/TC-516 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Affects Versions: 2.1.0 Reporter: Jeremy Mitchell There are currently 4 protocols for a DS: 0 - HTTP 1 - HTTPS 2 - HTTP AND HTTPS 3 - HTTP TO HTTPS Currently, if you delete a DS thru the API, SSL keys are not deleted. This should occur if ds.protocol > 0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-491) Deleting Delivery Service with associated job in job table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-491: -- Assignee: Jeremy Mitchell > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation > > > Key: TC-491 > URL: https://issues.apache.org/jira/browse/TC-491 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > > Deleting Delivery Service with associated job in job table fails due to > foreign key constraint violation. > E.g. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_job_deliveryservice1" on table "job" > DETAIL: Key (id)=(714) is still referenced from table "job". [for Statement > "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: 1='714'] at > /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: No UI/API end-point to delete the associated job. Delete > associated job from database. > NOTE: Other Traffic Ops versions may also be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-492) Deleting Delivery Service with associated static dns entry(s) in staticdnsentry table fails due to foreign key constraint violation
[ https://issues.apache.org/jira/browse/TC-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-492: -- Assignee: Jeremy Mitchell > Deleting Delivery Service with associated static dns entry(s) in > staticdnsentry table fails due to foreign key constraint violation > --- > > Key: TC-492 > URL: https://issues.apache.org/jira/browse/TC-492 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Robert Scrimo >Assignee: Jeremy Mitchell >Priority: Critical > > Deleting Delivery Service with associated static dns entry in staticdnsentry > table fails due to foreign key constraint violation. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute > failed: ERROR: update or delete on table "deliveryservice" violates foreign > key constraint "fk_staticdnsentry_ds" on table "staticdnsentry" > DETAIL: Key (id)=(180) is still referenced from table "staticdnsentry". [for > Statement "DELETE FROM deliveryservice WHERE ( id = ? )" with ParamValues: > 1='180'] at /opt/traffic_ops/app/lib/API/Deliveryservice.pm line 642 > Workaround: Use the UI to remove the association(s) before deleting the > delivery service. > NOTE: Other versions of Traffic Ops may be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-510) cannot apply ipv6 on delivery services
[
https://issues.apache.org/jira/browse/TC-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Mitchell updated TC-510:
---
Affects Version/s: 2.1.0
Component/s: (was: Traffic Portal)
> cannot apply ipv6 on delivery services
> --
>
> Key: TC-510
> URL: https://issues.apache.org/jira/browse/TC-510
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Sean Aoyagi
>
> attempt to change ipv6 flag from ipv4 to ipv6 results in a / unable to update
> delivery service.
> on trafficops, 2.1.0-6566.3980b417.el7 Also receive following error:
> {code}Traffic Ops fatal error occurred while processing your request.
> Error at line 50 (%= field('ds.cdn_id')->select( \@{$cdns} );)
> Global symbol "$cdns" requires explicit package name at template
> delivery_service/_form.html.ep line 50. Global symbol "$profiles" requires
> explicit package name at template delivery_service/_form.html.ep line
> 375.{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-510) cannot apply ipv6 on delivery services
[
https://issues.apache.org/jira/browse/TC-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Mitchell updated TC-510:
---
Attachment: (was: Pasted image at 2017_08_11 09_09 AM.png)
> cannot apply ipv6 on delivery services
> --
>
> Key: TC-510
> URL: https://issues.apache.org/jira/browse/TC-510
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops, Traffic Portal
>Reporter: Sean Aoyagi
>
> attempt to change ipv6 flag from ipv4 to ipv6 results in a / unable to update
> delivery service.
> on trafficops, 2.1.0-6566.3980b417.el7 Also receive following error:
> {code}Traffic Ops fatal error occurred while processing your request.
> Error at line 50 (%= field('ds.cdn_id')->select( \@{$cdns} );)
> Global symbol "$cdns" requires explicit package name at template
> delivery_service/_form.html.ep line 50. Global symbol "$profiles" requires
> explicit package name at template delivery_service/_form.html.ep line
> 375.{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TC-407) Cannot update a steering type delivery service via API
[
https://issues.apache.org/jira/browse/TC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122370#comment-16122370
]
Jeremy Mitchell commented on TC-407:
This code is supposed to skip the org server requirement check if type is
*steering* or any_map
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Deliveryservice.pm#L1371
can you ensure that the type of DS you are trying to update is truly of type
steering? I guess that would mean checking the typeId that is sent in with the
request and ensure that it lines up with a steering DS.
Also, I tried updating a STEERING ds via the api in 2.1.x branch and it seems
to work fine.
> Cannot update a steering type delivery service via API
> --
>
> Key: TC-407
> URL: https://issues.apache.org/jira/browse/TC-407
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Joseph Pappano
>Assignee: Jeremy Mitchell
>
> The API to update a delivery service requires an origin server FQDN. Steering
> type delivery services to not have one and the api fails with the following
> error.
> {code}
> {u'alerts': [{u'level': u'error', u'text': u'orgServerFqdn is required'}]}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (TC-407) Cannot update a steering type delivery service via API
[
https://issues.apache.org/jira/browse/TC-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Mitchell reassigned TC-407:
--
Assignee: Jeremy Mitchell
> Cannot update a steering type delivery service via API
> --
>
> Key: TC-407
> URL: https://issues.apache.org/jira/browse/TC-407
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Joseph Pappano
>Assignee: Jeremy Mitchell
>
> The API to update a delivery service requires an origin server FQDN. Steering
> type delivery services to not have one and the api fails with the following
> error.
> {code}
> {u'alerts': [{u'level': u'error', u'text': u'orgServerFqdn is required'}]}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TC-490) mso.qstring_handling parameter is checked but not documented
[
https://issues.apache.org/jira/browse/TC-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122330#comment-16122330
]
Jeremy Mitchell commented on TC-490:
I thought but you'd have to ask [~dg4prez] we were moving away from these UI
config file routes to the API config file routes -
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Configs/ApacheTrafficServer.pm
so be sure that if any changes are made in UI/ConfigFiles.pm, they are also
made in ApacheTrafficServer.pm
> mso.qstring_handling parameter is checked but not documented
>
>
> Key: TC-490
> URL: https://issues.apache.org/jira/browse/TC-490
> Project: Traffic Control
> Issue Type: Bug
> Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Matt Mills
>Priority: Blocker
>
> mso.qstring_handling not listed in docs, seems to be defined elsewhere as
> psel.qstring_handling
>but MID parent selection code checks if mso.qstring_handling is not defined
> {code}
>my $qsh=
> $ds->{'param'}->{'parent.config'}->{'mso.qstring_handling'};
>my $parent_qstring = "ignore";
> # default is ignore, unless for alg consistent_hash
>if ( !defined($qsh) && $mso_algorithm eq 'consistent_hash' &&
> $ds->{qstring_ignore} == 0 ) {
> $parent_qstring = 'consider';
>}
> {code}
> The parameter is unlikely to ever exist, since it's not documented anywhere,
> but either way either the code should be corrected or the documentation
> should be.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TC-500) Creating/Updating a Delivery Service via API has length constraint on displayName of 48, but no such constraint in UI code
[ https://issues.apache.org/jira/browse/TC-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122314#comment-16122314 ] Jeremy Mitchell commented on TC-500: This issue exists in the Legacy TO UI but not the new UI (Traffic Portal). In my opinion, the priority could probably be reduced. > Creating/Updating a Delivery Service via API has length constraint on > displayName of 48, but no such constraint in UI code > -- > > Key: TC-500 > URL: https://issues.apache.org/jira/browse/TC-500 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Robert Scrimo > > Creating/Updating a Delivery Service via API code has length constraint on > `displayName` of 48, but there is no such constraint in the UI code so any > user can update the value to more than 48 characters. The Database field is > Text which is described as "variable unlimited length" in the Postgres > documentation. However, the value may be limited by the GUI field if such a > constraint exists. > NOTE: The GET methods for /api/1.2/deliveryservices does not check the > length on the `displayName` field, so, it will return whatever is in the > database for `displayName`. > Work Around: Upon getting the Delivery Service information from the API, in > order to update/create the Delivery Service via the API you will need to > limit the number of characters in the `displayName` to 48. > NOTE: Other versions of Traffic Ops may be affected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-501) TPv2 installation - better defaults are required
[ https://issues.apache.org/jira/browse/TC-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122311#comment-16122311 ] Jeremy Mitchell commented on TC-501: or maybe you can change this to "improvement" rather than "bug". > TPv2 installation - better defaults are required > > > Key: TC-501 > URL: https://issues.apache.org/jira/browse/TC-501 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0 >Reporter: Nir Sopher > > After basic install of traffic-portal based on the documentation, traffic > portal failed to launch. this is due to relative pathes to the logs and > static files appear in the default configuration. > Note that the working directory of the server is "/" > First, the log path (./server/log) does not exists. A possible fix is to > change the dir to /opt/traffic_portal/server/log and create the log dir if > needed. > Second. the files static path should be set to "opt/traffic_portal/public" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-508) Import Profile may create parameters duplications
[ https://issues.apache.org/jira/browse/TC-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122307#comment-16122307 ] Jeremy Mitchell commented on TC-508: I'm not sure how that is possible given the fact that there is a unique constraint on the parameter table by name, config_file, value. If you look at your database do you see that constraint? > Import Profile may create parameters duplications > - > > Key: TC-508 > URL: https://issues.apache.org/jira/browse/TC-508 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Nir Sopher > > I had an ops server, loaded with the default profiles as published in the > web-site. > I tried to had an exported old ATS 5.3 profile as well. > It then created a situation where I have 2 parameters with the same "name, > file, value" set. > If for example I delete one of them, the other is deleted as well... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-505) LDAP only users are greeted with a 404 for all UI / API routes
[ https://issues.apache.org/jira/browse/TC-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-505. Resolution: Fixed Fix Version/s: 2.1.0 > LDAP only users are greeted with a 404 for all UI / API routes > -- > > Key: TC-505 > URL: https://issues.apache.org/jira/browse/TC-505 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops, Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Critical > Fix For: 2.1.0 > > > This is because not_ldap => 1 was added to all routes via this PR: > https://github.com/apache/incubator-trafficcontrol/pull/627 > which results in a 404 for all UI / API routes if you don't have a user entry > in the tm_user table. > Rather than 404, if you login as ldap-only, you should get a 403 (forbidden) > with a nice message about what you should do. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-501) TPv2 installation - better defaults are required
[ https://issues.apache.org/jira/browse/TC-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121764#comment-16121764 ] Jeremy Mitchell commented on TC-501: [~hbeatty] - I personally think this is a lower priority as [~nirsopher] wasn't aware of the comments that must be followed to get TP installed. [~nirsopher] - can you lower the priority or switch it to 2.2? > TPv2 installation - better defaults are required > > > Key: TC-501 > URL: https://issues.apache.org/jira/browse/TC-501 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0 >Reporter: Nir Sopher > > After basic install of traffic-portal based on the documentation, traffic > portal failed to launch. this is due to relative pathes to the logs and > static files appear in the default configuration. > Note that the working directory of the server is "/" > First, the log path (./server/log) does not exists. A possible fix is to > change the dir to /opt/traffic_portal/server/log and create the log dir if > needed. > Second. the files static path should be set to "opt/traffic_portal/public" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-505) LDAP only users are greeted with a 404 for all UI / API routes
Jeremy Mitchell created TC-505: -- Summary: LDAP only users are greeted with a 404 for all UI / API routes Key: TC-505 URL: https://issues.apache.org/jira/browse/TC-505 Project: Traffic Control Issue Type: Bug Components: Traffic Ops, Traffic Ops API Affects Versions: 2.1.0 Reporter: Jeremy Mitchell Assignee: Jeremy Mitchell Priority: Critical This is because not_ldap => 1 was added to all routes via this PR: https://github.com/apache/incubator-trafficcontrol/pull/627 which results in a 404 for all UI / API routes if you don't have a user entry in the tm_user table. Rather than 404, if you login as ldap-only, you should get a 403 (forbidden) with a nice message about what you should do. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-504) TPv2 - delivery service globalMaxMbps and globalMaxTps need to be verified as INT
[ https://issues.apache.org/jira/browse/TC-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-504. Resolution: Fixed > TPv2 - delivery service globalMaxMbps and globalMaxTps need to be verified as > INT > - > > Key: TC-504 > URL: https://issues.apache.org/jira/browse/TC-504 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0 >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell > Fix For: 2.1.0 > > > When creating or editing DNS* or HTTP* delivery services through the traffic > portal validation is currently occurring that prevents setting the value of > globalMaxMbps and globalMaxTps to its proper data type - INT. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-501) TPv2 installation - better defaults are required
[ https://issues.apache.org/jira/browse/TC-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16117099#comment-16117099 ] Jeremy Mitchell commented on TC-501: i’m not sure the best solution off the top of my head. the default values found in https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_portal/conf/config.js work well when you are in “dev” mode, aka when you have run `grunt` or `grunt dev` your output files are put in files in ./app/dist/public/ as the config.js file says and it starts an express server that will write an access.log to whereever you tell it to. by default i tell it to write it to `./server/log/access.log` but yes, when TP is installed, you need to change both of those values per the comments in that config.js file. > TPv2 installation - better defaults are required > > > Key: TC-501 > URL: https://issues.apache.org/jira/browse/TC-501 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Portal >Affects Versions: 2.1.0 >Reporter: Nir Sopher > > After basic install of traffic-portal based on the documentation, traffic > portal failed to launch. this is due to relative pathes to the logs and > static files appear in the default configuration. > Note that the working directory of the server is "/" > First, the log path (./server/log) does not exists. A possible fix is to > change the dir to /opt/traffic_portal/server/log and create the log dir if > needed. > Second. the files static path should be set to "opt/traffic_portal/public" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (TC-402) xml_id should not be changed after initial Delivery Service Creation
[ https://issues.apache.org/jira/browse/TC-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reopened TC-402: > xml_id should not be changed after initial Delivery Service Creation > > > Key: TC-402 > URL: https://issues.apache.org/jira/browse/TC-402 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Dewayne Richardson >Assignee: Jeremy Mitchell > Fix For: 2.1.0 > > > Traffic Ops cannot handle changing the xml_id because the parameters for the > ATS config files use the xml_id by naming convention. > Easy fix, just disable the 'xml_id' field for "Edit/Updates" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-402) xml_id should not be changed after initial Delivery Service Creation
[ https://issues.apache.org/jira/browse/TC-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell resolved TC-402. Resolution: Fixed Fix Version/s: 2.1.0 > xml_id should not be changed after initial Delivery Service Creation > > > Key: TC-402 > URL: https://issues.apache.org/jira/browse/TC-402 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Reporter: Dewayne Richardson >Assignee: Jeremy Mitchell > Fix For: 2.1.0 > > > Traffic Ops cannot handle changing the xml_id because the parameters for the > ATS config files use the xml_id by naming convention. > Easy fix, just disable the 'xml_id' field for "Edit/Updates" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-498) TO API - when updating current user, full name is required
Jeremy Mitchell created TC-498: -- Summary: TO API - when updating current user, full name is required Key: TC-498 URL: https://issues.apache.org/jira/browse/TC-498 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Reporter: Jeremy Mitchell Assignee: Jeremy Mitchell Priority: Minor case error caused validation to fail. see fullName vs full_name https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/User.pm#L646 https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/User.pm#L653 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-486) Add steering role to steering apis
[ https://issues.apache.org/jira/browse/TC-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Mitchell reassigned TC-486: -- Assignee: Jeremy Mitchell > Add steering role to steering apis > -- > > Key: TC-486 > URL: https://issues.apache.org/jira/browse/TC-486 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Reporter: Jeremy Mitchell >Assignee: Jeremy Mitchell >Priority: Minor > > Create, update and delete of steering targets should be available to users > with the "steering" role. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
