[jira] [Resolved] (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
]
Nir Sopher resolved TC-535.
---
Resolution: Fixed
> 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] [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=16139010#comment-16139010 ] Nir Sopher commented on TC-550: --- What is the purpose of this endpoint? When writing the code I considered it as a "read" endpoint to the DS/User table, not as "give me the list of DSes another user can see". Nir > 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] [Comment Edited] (TC-384) Profiles exported from TC1.7 cannot be imported to TC 2.1
[ https://issues.apache.org/jira/browse/TC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130943#comment-16130943 ] Nir Sopher edited comment on TC-384 at 8/17/17 6:16 PM: The "type" should added to the "profile" dictionary in the profile json. For example "type":"ATS_PROFILE". The below command should do the trick (for ATS_PROFILE): sed -i -- 's/}}/,"type":"ATS_PROFILE"}}/g' * [~dangogh] I agree it better appear in the RN. How do we do that. was (Author: nirsopher): The "type" should added to the "profile" dictionary in the profile json. For example "type":"ATS_PROFILE". The below command should do the trick (for ATS_PROFILE): sed -i -- 's/}}/,"type":"ATS_PROFILE"}}/g' * [~dangogh] I think it better appear in the RN. How do we do that. > Profiles exported from TC1.7 cannot be imported to TC 2.1 > - > > Key: TC-384 > URL: https://issues.apache.org/jira/browse/TC-384 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Nir Sopher >Assignee: Dan Kirkwood > Labels: profile_parameters > > Due to a missing "profile-type" in the 1.7 json, the profiles cannot be > imported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-384) Profiles exported from TC1.7 cannot be imported to TC 2.1
[ https://issues.apache.org/jira/browse/TC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130943#comment-16130943 ] Nir Sopher commented on TC-384: --- The "type" should added to the "profile" dictionary in the profile json. For example "type":"ATS_PROFILE". The below command should do the trick (for ATS_PROFILE): sed -i -- 's/}}/,"type":"ATS_PROFILE"}}/g' * [~dangogh] I think it better appear in the RN. How do we do that. > Profiles exported from TC1.7 cannot be imported to TC 2.1 > - > > Key: TC-384 > URL: https://issues.apache.org/jira/browse/TC-384 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Nir Sopher >Assignee: Dan Kirkwood > Labels: profile_parameters > > Due to a missing "profile-type" in the 1.7 json, the profiles cannot be > imported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-384) Profiles exported from TC1.7 cannot be imported to TC 2.1
[ https://issues.apache.org/jira/browse/TC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128655#comment-16128655 ] Nir Sopher commented on TC-384: --- Waiting for 2.2 will make it irrelevant. I think it can be dismissed. If someone needs to import a profile he should manually add the profile-type to the json > Profiles exported from TC1.7 cannot be imported to TC 2.1 > - > > Key: TC-384 > URL: https://issues.apache.org/jira/browse/TC-384 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Nir Sopher >Assignee: Dan Kirkwood > Labels: profile_parameters > > Due to a missing "profile-type" in the 1.7 json, the profiles cannot be > imported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-384) Profiles exported from TC1.7 cannot be imported to TC 2.1
[ https://issues.apache.org/jira/browse/TC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-384: -- Issue Type: Improvement (was: Bug) > Profiles exported from TC1.7 cannot be imported to TC 2.1 > - > > Key: TC-384 > URL: https://issues.apache.org/jira/browse/TC-384 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Nir Sopher >Assignee: Dan Kirkwood > Labels: profile_parameters > > Due to a missing "profile-type" in the 1.7 json, the profiles cannot be > imported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-531) Traffic Monitor does not pull new cr-config when all servers in in "ONLINE" and not "REPORTED"
Nir Sopher created TC-531: - Summary: Traffic Monitor does not pull new cr-config when all servers in in "ONLINE" and not "REPORTED" Key: TC-531 URL: https://issues.apache.org/jira/browse/TC-531 Project: Traffic Control Issue Type: Bug Components: Traffic Monitor (golang) Affects Versions: 2.1.0 Reporter: Nir Sopher Priority: Minor When all cache servers are forced to be ONLINE, TM seems not to pull the cfg, with the below message in the log "No REPORTED caches exist in Traffic Ops, nothing to poll." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-530) TRAFFIC_ROUTER default profile points to non existing coverage-zone DB endpoint
Nir Sopher created TC-530:
-
Summary: TRAFFIC_ROUTER default profile points to non existing
coverage-zone DB endpoint
Key: TC-530
URL: https://issues.apache.org/jira/browse/TC-530
Project: Traffic Control
Issue Type: Improvement
Components: Documentation
Affects Versions: 2.1.0
Reporter: Nir Sopher
Priority: Minor
The "coveragezone.polling.url" variable in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
is set to http://${toHostname}/cdn/CZF/current/czf-current.json
However, this path does not exists in my traffic ops.
However, the path "routing/coverage-zone.json" does exists
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-526) TM does not pull configuration where no DS/Server assignment exists
[
https://issues.apache.org/jira/browse/TC-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-526:
--
Description:
When DSes and Servers are already configured in traffic-ops, cr-config can be
generated.
However, TM (and therefore the TR) ignores the cr-config if there is no
DS/Server assignment ("MonitorConfigPoller: skipping this iteration, Session is
nil").
As the cr-config hold much more than this mapping, I would like to suggest the
configuration would not be ignored.
> TM does not pull configuration where no DS/Server assignment exists
> ---
>
> Key: TC-526
> URL: https://issues.apache.org/jira/browse/TC-526
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Monitor (golang)
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
> When DSes and Servers are already configured in traffic-ops, cr-config can be
> generated.
> However, TM (and therefore the TR) ignores the cr-config if there is no
> DS/Server assignment ("MonitorConfigPoller: skipping this iteration, Session
> is nil").
> As the cr-config hold much more than this mapping, I would like to suggest
> the configuration would not be ignored.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-527) Traffic_Router Default Profile - Uses unsupported pattern (${toHostname})
[
https://issues.apache.org/jira/browse/TC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-527:
--
Description:
Few variables in the TRAFFIC_ROUTER default profile published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
uses the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
I would suggest to add a "README" besides the default profile, with
instructions to replace this pattern manually (until TR supports it)
> Traffic_Router Default Profile - Uses unsupported pattern (${toHostname})
> -
>
> Key: TC-527
> URL: https://issues.apache.org/jira/browse/TC-527
> Project: Traffic Control
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 2.1.0
> Environment: Few variables in the TRAFFIC_ROUTER default profile
> published at
> http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
> uses the pattern ${toHostname}, however, at least till commit
> 3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace
> this pattern with the ops hostname.
> I would suggest to add a "README" besides the default profile, with
> instructions to replace this pattern manually (until TR supports it)
>Reporter: Nir Sopher
>Priority: Minor
>
> Few variables in the TRAFFIC_ROUTER default profile published at
> http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
> uses the pattern ${toHostname}, however, at least till commit
> 3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace
> this pattern with the ops hostname.
> I would suggest to add a "README" besides the default profile, with
> instructions to replace this pattern manually (until TR supports it)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-526) TM does not pull configuration where no DS/Server assignment exists
[
https://issues.apache.org/jira/browse/TC-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-526:
--
Environment: (was: When DSes and Servers are already configured in
traffic-ops, cr-config can be generated.
However, TM (and therefore the TR) ignores the cr-config if there is no
DS/Server assignment ("MonitorConfigPoller: skipping this iteration, Session is
nil").
As the cr-config hold much more than this mapping, I would like to suggest the
configuration would not be ignored.)
> TM does not pull configuration where no DS/Server assignment exists
> ---
>
> Key: TC-526
> URL: https://issues.apache.org/jira/browse/TC-526
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Monitor (golang)
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-528) Traffic Router - To support the ${toHostname} pattern when parsing the cr-config
[
https://issues.apache.org/jira/browse/TC-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-528:
--
Description:
Few variables in the TRAFFIC_ROUTER default profile published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
use the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
> Traffic Router - To support the ${toHostname} pattern when parsing the
> cr-config
>
>
> Key: TC-528
> URL: https://issues.apache.org/jira/browse/TC-528
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Router
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
> Few variables in the TRAFFIC_ROUTER default profile published at
> http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
> use the pattern ${toHostname}, however, at least till commit
> 3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace
> this pattern with the ops hostname.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-528) Traffic Router - To support the ${toHostname} pattern when parsing the cr-config
[
https://issues.apache.org/jira/browse/TC-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-528:
--
Environment: (was: Few variables in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
use the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
)
> Traffic Router - To support the ${toHostname} pattern when parsing the
> cr-config
>
>
> Key: TC-528
> URL: https://issues.apache.org/jira/browse/TC-528
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Router
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TC-529) TRAFFIC_ROUTER default profile points to non existing geolocation DB endpoint
[
https://issues.apache.org/jira/browse/TC-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nir Sopher updated TC-529:
--
Description:
The "geolocation.polling.url" variable in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
is set to http://${toHostname}/MaxMind/auto/GeoIP2-City.mmdb.gz.
However, this path does not exists in my traffic ops.
However, the path "routing/GeoLite2-City.mmdb.gz" does exists
was:
The "eolocation.polling.url" variable in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
is set to http://${toHostname}/MaxMind/auto/GeoIP2-City.mmdb.gz.
However, this path does not exists in my traffic ops.
However, the path "routing/GeoLite2-City.mmdb.gz" does exists
> TRAFFIC_ROUTER default profile points to non existing geolocation DB endpoint
> -
>
> Key: TC-529
> URL: https://issues.apache.org/jira/browse/TC-529
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Router
>Affects Versions: 2.1.0
>Reporter: Nir Sopher
>Priority: Minor
>
> The "geolocation.polling.url" variable in the TRAFFIC_ROUTER default profile
> published at
> http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
> is set to http://${toHostname}/MaxMind/auto/GeoIP2-City.mmdb.gz.
> However, this path does not exists in my traffic ops.
> However, the path "routing/GeoLite2-City.mmdb.gz" does exists
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-529) TRAFFIC_ROUTER default profile points to non existing geolocation DB endpoint
Nir Sopher created TC-529:
-
Summary: TRAFFIC_ROUTER default profile points to non existing
geolocation DB endpoint
Key: TC-529
URL: https://issues.apache.org/jira/browse/TC-529
Project: Traffic Control
Issue Type: Improvement
Components: Traffic Router
Affects Versions: 2.1.0
Reporter: Nir Sopher
Priority: Minor
The "eolocation.polling.url" variable in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
is set to http://${toHostname}/MaxMind/auto/GeoIP2-City.mmdb.gz.
However, this path does not exists in my traffic ops.
However, the path "routing/GeoLite2-City.mmdb.gz" does exists
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-528) Traffic Router - To support the ${toHostname} pattern when parsing the cr-config
Nir Sopher created TC-528:
-
Summary: Traffic Router - To support the ${toHostname} pattern
when parsing the cr-config
Key: TC-528
URL: https://issues.apache.org/jira/browse/TC-528
Project: Traffic Control
Issue Type: Improvement
Components: Traffic Router
Affects Versions: 2.1.0
Environment: Few variables in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
use the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
Reporter: Nir Sopher
Priority: Minor
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-527) Traffic_Router Default Profile - Uses unsupported pattern (${toHostname})
Nir Sopher created TC-527:
-
Summary: Traffic_Router Default Profile - Uses unsupported pattern
(${toHostname})
Key: TC-527
URL: https://issues.apache.org/jira/browse/TC-527
Project: Traffic Control
Issue Type: Improvement
Components: Documentation
Affects Versions: 2.1.0
Environment: Few variables in the TRAFFIC_ROUTER default profile
published at
http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/TRAFFIC_ROUTER_PROFILE.traffic_ops
uses the pattern ${toHostname}, however, at least till commit
3980b41797c8f2b616277df4b74e73a011c48869, traffic router does not replace this
pattern with the ops hostname.
I would suggest to add a "README" besides the default profile, with
instructions to replace this pattern manually (until TR supports it)
Reporter: Nir Sopher
Priority: Minor
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TC-525) Cannot snapshot CrConfig when no mid server exists
Nir Sopher created TC-525: - Summary: Cannot snapshot CrConfig when no mid server exists Key: TC-525 URL: https://issues.apache.org/jira/browse/TC-525 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher Traffic Control works well with no MID servers. The edge server can just work against the origin. However, if no "MID" server exists, snapshot cr-config fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TC-508) Import Profile may create parameters duplications
[ https://issues.apache.org/jira/browse/TC-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher closed TC-508. - Resolution: Invalid Jeremy is correct. I was probably confused due to the appearance of the same variable twice in the list (once per profile) > 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] [Updated] (TC-501) TPv2 installation - better defaults are required
[ https://issues.apache.org/jira/browse/TC-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-501: -- Issue Type: Improvement (was: Bug) > TPv2 installation - better defaults are required > > > Key: TC-501 > URL: https://issues.apache.org/jira/browse/TC-501 > Project: Traffic Control > Issue Type: Improvement > 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-508) Import Profile may create parameters duplications
Nir Sopher created TC-508: - Summary: 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-428) Tenancy based access control - Delivery Service API
[ https://issues.apache.org/jira/browse/TC-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-428. --- Resolution: Fixed Fix Version/s: 2.1.0 > Tenancy based access control - Delivery Service API > --- > > Key: TC-428 > URL: https://issues.apache.org/jira/browse/TC-428 > Project: Traffic Control > Issue Type: Improvement >Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with "delivery-service as a resource". We enforce access > control via the API to the different users. > We also add a naive change in the UI - presenting the logged in user only > delivery-services users he has access to. > This JIRA does not deal with indirect tenancy (e.g DS/Regex table) - we will > deal with it in following JIRAs -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-459) User default tenancy should be "none"
[ https://issues.apache.org/jira/browse/TC-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-459. --- Resolution: Fixed Fix Version/s: 2.1.0 > User default tenancy should be "none" > - > > Key: TC-459 > URL: https://issues.apache.org/jira/browse/TC-459 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > Fix For: 2.1.0 > > > Currently the default tenancy is the tenancy if the creating user. > This may cause the creation of too powerful tenants by mistake. > Better give the new user no tenancy and set it later on -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-461) Delivery-service tenancy based access control - Steering Target
[ https://issues.apache.org/jira/browse/TC-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-461. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - Steering Target > --- > > Key: TC-461 > URL: https://issues.apache.org/jira/browse/TC-461 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher >Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS steering target: In order to add a > steering target DS1 to steering DS ST1, the user should have access to the > tenants of DS1 and ST1. In order to read the record, access to ST1 is enough -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-460) Delivery-service tenancy based access control - DS/Server Assignment
[ https://issues.apache.org/jira/browse/TC-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-460. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - DS/Server Assignment > > > Key: TC-460 > URL: https://issues.apache.org/jira/browse/TC-460 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS assignment to servers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-463) Delivery-service tenancy based access control - DS/User Assignment
[ https://issues.apache.org/jira/browse/TC-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher reassigned TC-463: - Assignee: Nir Sopher > Delivery-service tenancy based access control - DS/User Assignment > --- > > Key: TC-463 > URL: https://issues.apache.org/jira/browse/TC-463 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher >Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" as well > as "user as a resource" - enforcing via the API access control on DS to User: > The logged in user should have access to both the DS as well as the user > assigned to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-461) Delivery-service tenancy based access control - Steering Target
[ https://issues.apache.org/jira/browse/TC-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher reassigned TC-461: - Assignee: Nir Sopher > Delivery-service tenancy based access control - Steering Target > --- > > Key: TC-461 > URL: https://issues.apache.org/jira/browse/TC-461 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher >Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS steering target: In order to add a > steering target DS1 to steering DS ST1, the user should have access to the > tenants of DS1 and ST1. In order to read the record, access to ST1 is enough -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-462) Delivery-service tenancy based access control - Regexes
[ https://issues.apache.org/jira/browse/TC-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher reassigned TC-462: - Assignee: Nir Sopher > Delivery-service tenancy based access control - Regexes > --- > > Key: TC-462 > URL: https://issues.apache.org/jira/browse/TC-462 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher >Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS regexes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-471) Delivery-service tenancy based access control - ignore-tenancy parameter change
[ https://issues.apache.org/jira/browse/TC-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-471. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - ignore-tenancy parameter > change > --- > > Key: TC-471 > URL: https://issues.apache.org/jira/browse/TC-471 > Project: Traffic Control > Issue Type: Improvement >Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > The "ignore-tenancy" variable comes to allow the disablement of the tenancy > mechanism. > It was decided to change the default of this variable to "true". It was also > decided to ignore the DS/User assignment if the "ignore-tenancy" is false. > During the transition, the user should set the tenancy of all DSes, > then enable tenancy, finalaly, he can clear the DS/User table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TC-471) Delivery-service tenancy based access control - ignore-tenancy parameter change
[ https://issues.apache.org/jira/browse/TC-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher reassigned TC-471: - Assignee: Nir Sopher > Delivery-service tenancy based access control - ignore-tenancy parameter > change > --- > > Key: TC-471 > URL: https://issues.apache.org/jira/browse/TC-471 > Project: Traffic Control > Issue Type: Improvement >Reporter: Nir Sopher >Assignee: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > The "ignore-tenancy" variable comes to allow the disablement of the tenancy > mechanism. > It was decided to change the default of this variable to "true". It was also > decided to ignore the DS/User assignment if the "ignore-tenancy" is false. > During the transition, the user should set the tenancy of all DSes, > then enable tenancy, finalaly, he can clear the DS/User table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-485) Steering Target API - Redundent parameters
[ https://issues.apache.org/jira/browse/TC-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-485. --- Resolution: Fixed Fix Version/s: 2.1.0 > Steering Target API - Redundent parameters > -- > > Key: TC-485 > URL: https://issues.apache.org/jira/browse/TC-485 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Nir Sopher > Fix For: 2.1.0 > > > Traffic Ops POST endpoint for "/api/1.2/steering" have the > delivery-service and target IDs in the path, but use the values retrieved as > parameters. > Therefore, these parameters needs to be removed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-478) Parameter value cannot be set to "0" using the parameters crud API
[ https://issues.apache.org/jira/browse/TC-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-478. --- Resolution: Fixed Fix Version/s: 2.1.0 > Parameter value cannot be set to "0" using the parameters crud API > -- > > Key: TC-478 > URL: https://issues.apache.org/jira/browse/TC-478 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops API >Affects Versions: 2.1.0 >Reporter: Nir Sopher > Fix For: 2.1.0 > > > Example: > Having a parameter with value=="1" > Trying to "PUT" a value of "0" in this parameter. > The value of the parameter stays "1". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-462) Delivery-service tenancy based access control - Regexes
[ https://issues.apache.org/jira/browse/TC-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-462. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - Regexes > --- > > Key: TC-462 > URL: https://issues.apache.org/jira/browse/TC-462 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing via the API access control on DS regexes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-463) Delivery-service tenancy based access control - DS/User Assignment
[ https://issues.apache.org/jira/browse/TC-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-463. --- Resolution: Fixed Fix Version/s: 2.1.0 > Delivery-service tenancy based access control - DS/User Assignment > --- > > Key: TC-463 > URL: https://issues.apache.org/jira/browse/TC-463 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" as well > as "user as a resource" - enforcing via the API access control on DS to User: > The logged in user should have access to both the DS as well as the user > assigned to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-427) Tenancy Based Access Control - User Resource
[ https://issues.apache.org/jira/browse/TC-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-427. --- Resolution: Fixed Fix Version/s: 2.1.0 > Tenancy Based Access Control - User Resource > > > Key: TC-427 > URL: https://issues.apache.org/jira/browse/TC-427 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops API >Reporter: Nir Sopher > Fix For: 2.1.0 > > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with "user as a resource". We enforce access control via the > API to the different users. > We also add a naive change in the UI - presenting the logged in user only > users he has access to. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TC-398) Create User API - Broken due to merge issue
[ https://issues.apache.org/jira/browse/TC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher resolved TC-398. --- Resolution: Fixed > Create User API - Broken due to merge issue > --- > > Key: TC-398 > URL: https://issues.apache.org/jira/browse/TC-398 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Nir Sopher >Assignee: Nir Sopher > Fix For: 2.1.0 > > > "Create" user API was recently added to TO. > Additionally, TO password hashing was changed to scrypt. > The merge between the 2 changes left the "create" command with the old "sha1" > calls. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-501) TPv2 installation - better defaults are required
Nir Sopher created TC-501: - Summary: 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-485) Steering Target API - Redundent parameters
Nir Sopher created TC-485: - Summary: Steering Target API - Redundent parameters Key: TC-485 URL: https://issues.apache.org/jira/browse/TC-485 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Affects Versions: 2.1.0 Reporter: Nir Sopher Traffic Ops POST endpoint for "/api/1.2/steering" have the delivery-service and target IDs in the path, but use the values retrieved as parameters. Therefore, these parameters needs to be removed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-478) Parameter value cannot be set to "0" using the parameters crud API
Nir Sopher created TC-478: - Summary: Parameter value cannot be set to "0" using the parameters crud API Key: TC-478 URL: https://issues.apache.org/jira/browse/TC-478 Project: Traffic Control Issue Type: Bug Components: Traffic Ops API Affects Versions: 2.1.0 Reporter: Nir Sopher Example: Having a parameter with value=="1" Trying to "PUT" a value of "0" in this parameter. The value of the parameter stays "1". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-464) Delivery-service tenancy based access control - Federation
[ https://issues.apache.org/jira/browse/TC-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-464: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing access control on Federations. We still need to finalize the specification of this access control.the TC was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on Federations. We still need to finalize the specification of this access control.the TC > Delivery-service tenancy based access control - Federation > -- > > Key: TC-464 > URL: https://issues.apache.org/jira/browse/TC-464 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing access control on Federations. > We still need to finalize the specification of this access control.the TC -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-466) Delivery-service tenancy based access control - statidnsentry
[ https://issues.apache.org/jira/browse/TC-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-466: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing access control on static-dns-entry, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries of DSes which are not under his tenancy. was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on static-dns-entry, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries of DSes which are not under his tenancy. > Delivery-service tenancy based access control - statidnsentry > - > > Key: TC-466 > URL: https://issues.apache.org/jira/browse/TC-466 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing access control on static-dns-entry, according to their Delivery > service. > We still need to finalize the specification of this access control, and it > would not be included in the first phase of tenancy introduction, assuming > that the application hide from the user the ability to deal with entries of > DSes which are not under his tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-467) Delivery-service tenancy based access control - DNSSEC and SSL Keys
[ https://issues.apache.org/jira/browse/TC-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-467: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing access control on the management of ssl keys and DNSSEC, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries relating to DSes which are not under his tenancy. was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on the management of ssl keys and DNSSEC, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries relating to DSes which are not under his tenancy. > Delivery-service tenancy based access control - DNSSEC and SSL Keys > --- > > Key: TC-467 > URL: https://issues.apache.org/jira/browse/TC-467 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing access control on the management of ssl keys and DNSSEC, according > to their Delivery service. > We still need to finalize the specification of this access control, and it > would not be included in the first phase of tenancy introduction, assuming > that the application hide from the user the ability to deal with entries > relating to DSes which are not under his tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-465) Delivery-service tenancy based access control - JOBs
[ https://issues.apache.org/jira/browse/TC-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-465: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing access control on Jobs, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with DSes which are not under his tenancy. was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on Jobs, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with DSes which are not under his tenancy. > Delivery-service tenancy based access control - JOBs > > > Key: TC-465 > URL: https://issues.apache.org/jira/browse/TC-465 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "delivery-service as a resource" - > enforcing access control on Jobs, according to their Delivery service. > We still need to finalize the specification of this access control, and it > would not be included in the first phase of tenancy introduction, assuming > that the application hide from the user the ability to deal with DSes which > are not under his tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-469) User tenancy based access control - log
[ https://issues.apache.org/jira/browse/TC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-469: -- Description: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "user as a resource" - enforcing access control to log records, according to their user tenancy. was: We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "user as a resource" - enforcing via the API access control , according to their Delivery service.to the log records with proper user tenancy. > User tenancy based access control - log > --- > > Key: TC-469 > URL: https://issues.apache.org/jira/browse/TC-469 > Project: Traffic Control > Issue Type: Improvement > Components: Traffic Ops >Reporter: Nir Sopher > > We have recently added "tenancy" to the project. > With tenancy, every resource have a tenant, where resource can be a > delivery-service, a server (future) and even a user. > We are now starting to enforce access-control based on the resource tenancy. > A user can manage a resource only if the resource is under the user tenancy. > This JIRA deals with another step of "user as a resource" - enforcing access > control to log records, according to their user tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-469) User tenancy based access control - log
Nir Sopher created TC-469: - Summary: User tenancy based access control - log Key: TC-469 URL: https://issues.apache.org/jira/browse/TC-469 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "user as a resource" - enforcing via the API access control , according to their Delivery service.to the log records with proper user tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-466) Delivery-service tenancy based access control - statidnsentry
Nir Sopher created TC-466: - Summary: Delivery-service tenancy based access control - statidnsentry Key: TC-466 URL: https://issues.apache.org/jira/browse/TC-466 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on static-dns-entry, according to their Delivery service. We still need to finalize the specification of this access control, and it would not be included in the first phase of tenancy introduction, assuming that the application hide from the user the ability to deal with entries of DSes which are not under his tenancy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-464) Delivery-service tenancy based access control - Federation
Nir Sopher created TC-464: - Summary: Delivery-service tenancy based access control - Federation Key: TC-464 URL: https://issues.apache.org/jira/browse/TC-464 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on Federations. We still need to finalize the specification of this access control.the TC -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-463) Delivery-service tenancy based access control - DS/User Assignment
Nir Sopher created TC-463: - Summary: Delivery-service tenancy based access control - DS/User Assignment Key: TC-463 URL: https://issues.apache.org/jira/browse/TC-463 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" as well as "user as a resource" - enforcing via the API access control on DS to User: The logged in user should have access to both the DS as well as the user assigned to it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-462) Delivery-service tenancy based access control - Regexes
Nir Sopher created TC-462: - Summary: Delivery-service tenancy based access control - Regexes Key: TC-462 URL: https://issues.apache.org/jira/browse/TC-462 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on DS regexes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-460) Delivery-service tenancy based access control - DS/Server Assignment
Nir Sopher created TC-460: - Summary: Delivery-service tenancy based access control - DS/Server Assignment Key: TC-460 URL: https://issues.apache.org/jira/browse/TC-460 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with another step of "delivery-service as a resource" - enforcing via the API access control on DS assignment to servers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-428) Tenancy based access control - Delivery Service API
Nir Sopher created TC-428: - Summary: Tenancy based access control - Delivery Service API Key: TC-428 URL: https://issues.apache.org/jira/browse/TC-428 Project: Traffic Control Issue Type: Improvement Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with "delivery-service as a resource". We enforce access control via the API to the different users. We also add a naive change in the UI - presenting the logged in user only delivery-services users he has access to. This JIRA does not deal with indirect tenancy (e.g DS/Regex table) - we will deal with it in following JIRAs -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-427) Tenancy Based Access Control - User Resource
Nir Sopher created TC-427: - Summary: Tenancy Based Access Control - User Resource Key: TC-427 URL: https://issues.apache.org/jira/browse/TC-427 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops API Reporter: Nir Sopher We have recently added "tenancy" to the project. With tenancy, every resource have a tenant, where resource can be a delivery-service, a server (future) and even a user. We are now starting to enforce access-control based on the resource tenancy. A user can manage a resource only if the resource is under the user tenancy. This JIRA deals with "user as a resource". We enforce access control via the API to the different users. We also add a naive change in the UI - presenting the logged in user only users he has access to. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TC-412) Currently when a delivery service encounters an error we currently don’t know how to find the owner to notify them of the outage or contact them to find cause of issue.
[ https://issues.apache.org/jira/browse/TC-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16076233#comment-16076233 ] Nir Sopher commented on TC-412: --- Hi William, Regarding the addition of owner to each DS. Are you going to use some already existing fields? Will it be done using the DS table, using a new table, or by extending the ds_tmuser table (adding a "go-to-on-troubles" bool for the relevant users)? > Currently when a delivery service encounters an error we currently don’t know > how to find the owner to notify them of the outage or contact them to find > cause of issue. > > > Key: TC-412 > URL: https://issues.apache.org/jira/browse/TC-412 > Project: Traffic Control > Issue Type: New Feature >Reporter: William Brown III > > *What do we want to accomplish?* > Fix information pages on Traffic Portal to better display issues with > existing delivery services and enforce delivery services to have contact > information about their owners. We will add this to the new Traffic Portal > only. These changes may range to affect UI, API and backing database tables. > We will first make the UI changes, and then go into an effort to add owners > to existing delivery services and once we are clear that all exiting services > have owners, we will update the API and database tables to lessen the risk of > a database migration error. > *What is needed to fix/update it?* > * Configure database tables (not null fields) to enforce changes > * Change column names to have an easier effect for what is being shown > * Combo boxes to enforce and reduce the amount of risk when entering an owner > * Add a tenant/audit field to a delivery services input page > * General UI updates to interact with pages > * Either use the staging environment that currently exists (link above), or > create a traffic ops environment of own > * Finding owners of existing delivery services and add them to existing > services > We will change the code that currently exists in > https://github.com/apache/incubator-trafficcontrol/, which is AngularJS and > nodeJS code, to support our desired features above. To update the code for > the API we will have to add features in Perl to the needed TrafficOps API as > well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-398) Create User API - Broken due to merge issue
Nir Sopher created TC-398: - Summary: Create User API - Broken due to merge issue Key: TC-398 URL: https://issues.apache.org/jira/browse/TC-398 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Affects Versions: 2.1.0 Reporter: Nir Sopher Fix For: 2.1.0 "Create" user API was recently added to TO. Additionally, TO password hashing was changed to scrypt. The merge between the 2 changes left the "create" command with the old "sha1" calls. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TC-384) Profiles exported from TC1.7 cannot be imported to TC 2.1
[ https://issues.apache.org/jira/browse/TC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nir Sopher updated TC-384: -- Description: Due to a missing "profile-type" in the 1.7 json, the profiles cannot be imported. was: Do to a missing "profile-type" in the 1.7 json, the profiles cannot be imported. > Profiles exported from TC1.7 cannot be imported to TC 2.1 > - > > Key: TC-384 > URL: https://issues.apache.org/jira/browse/TC-384 > Project: Traffic Control > Issue Type: Bug > Components: Traffic Ops >Affects Versions: 2.1.0 >Reporter: Nir Sopher > > Due to a missing "profile-type" in the 1.7 json, the profiles cannot be > imported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TC-332) Heatlh tab never loads if there are no traffic monitors
Nir Sopher created TC-332: - Summary: Heatlh tab never loads if there are no traffic monitors Key: TC-332 URL: https://issues.apache.org/jira/browse/TC-332 Project: Traffic Control Issue Type: Bug Components: Traffic Ops Reporter: Nir Sopher Priority: Minor Based on: https://github.com/Comcast/traffic_control/issues/494 by petrocc: If there are no traffic monitors the health tab sits at "loading...". This is probably not desired behavior. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TC-317) ORT syncds bug
Nir Sopher created TC-317: - Summary: ORT syncds bug Key: TC-317 URL: https://issues.apache.org/jira/browse/TC-317 Project: Traffic Control Issue Type: Bug Reporter: Nir Sopher Based on: https://github.com/Comcast/traffic_control/issues/1380 By: jpappa200 A parent from a different CDN can hold up a child from running syncds if Traffic Ops has multiple CDN's configured. https:///update/ looks at all parents associated with the cache group and doesn't check which CDN it's associated with. Comment by jeffmart: Is this hold up indefinite? or does syncds complete on the child after all parents for all CDNs in that cache group are updated? I am assuming https://github.com/Comcast/traffic_control/pull/2 but want to make sure knutsel : so we have a issue somewhere to take regex_revalidate out of the ort/syncds distribution mechanism, and scp (or ansible dist) it directly on update; this would remove the "mids have to complete ort syncds before edges" requirement, and things should get a lot better when we do that... -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TC-304) Ping each Riak server
Nir Sopher created TC-304: - Summary: Ping each Riak server Key: TC-304 URL: https://issues.apache.org/jira/browse/TC-304 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher Based on: https://github.com/Comcast/traffic_control/issues/1306 We should connect to (ping) each Riak server on startup to make sure that we have an SSL session established. Perhaps we should ping() each Riak server before marking it "online"? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TC-299) TO Change Log. Expand status to human readable string
Nir Sopher created TC-299: - Summary: TO Change Log. Expand status to human readable string Key: TC-299 URL: https://issues.apache.org/jira/browse/TC-299 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher Opened on bugs scrub, based on https://github.com/Comcast/traffic_control/issues/620 smalenfant: Sometimes I've got a hard time following what Ops is doing. Having a better understanding from the Change log would help a long way... I can't tell what happened here without knowing that "6" is OFFLINE. We should be expand this easily. Would also be nice to see the "From Status" to "To Status". 2015-09-15 12:27:04 UICHANGEUpdate server edge04 status->6 user 2015-09-15 12:26:52 UICHANGEUpdate server edge03 status->6 user 2015-09-15 12:26:41 UICHANGEUpdate server edge02 status->6 user 2015-09-15 12:26:28 UICHANGEUpdate server edge01 status->6 user Sometime we see the following.. probably different code path. 2015-09-18 13:20:23 UICHANGEUpdate server edge04.kabletown.net new status = REPORTED user 2015-09-18 13:20:18 UICHANGEUpdate server edge02.kabletown.nett new status = REPORTED user dewrich: If you can make a list of all of the Change Log tweaks you'd like to see like this, I will put it in the backlog to enhance them. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (TC-217) Self Service - CRUD Sub Tenant
[ https://issues.apache.org/jira/browse/TC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972417#comment-15972417 ] Nir Sopher edited comment on TC-217 at 4/18/17 12:42 PM: - Hi, I believe we need to distinguish between the 2 terminologies: "descendent-tenants", and "allowed-tenants". A tenants has "descendent-tenants", all the tenants beneath it in the hierarchy. A user has its "allowed-tenants" - tenants he can view and manage. Currently, the to terms are closely related - the "allowed-tenants" of a user are the "descendent-tenants" of the user's tenant. But this is not necessarily the case. There are a few futuristic examples for users need to be able to view tenants not in his own tenant hierarchy. For example, when we have multiple ISPs in the TC, none of which can be "root" tenant, but the users of this tenants need to be able to view "org-tenants" in order to work with their delivery services. Therefore we suggested that: api/1.2/tenants - will show all tenants. Only tenants viewable to the current user will be shown. api/1.2/tenants/:id/subtenants - will show all "tenants" decendent to the specified one (still, under the limitation of what the current user can view) Do we need additionally api/1.2/users/:id/tenants - get all the tenants viewable to the specified user (still, under the limitation of what the current user can view) ? Nir was (Author: nirsopher): Hi, I believe we need to distinguish between the 2 terminologies: "descendent-tenants", and "allowed-tenants". A tenants has "descendent-tenants", all the tenants beneath it in the hierarchy. A user has its "allowed-tenants" - tenants he can view and manage. Currently, the to terms are closely related - the "allowed-tenants" of a user are the "descendent-tenants" of the user's tenant. But this is not necessarily the case. There are a few futuristic examples for users need to be able to view tenants not in his own tenant hierarchy. For example, when we have multiple ISPs in the TC, none of which can be "root" tenant, but the users of this tenants need to be able to view "org-tenants" in order to work with their delivery services. Therefore we suggested that: api/1.2/tenants - will show all tenants view-able to the current user. api/1.2/tenants/:id/subtenants - will show all "tenants" decendent to the specified one (still, under the limitation of what the current user can view) Do we need additionally api/1.2/users/:id/tenants - get all the tenants viewable to the specified user (still, under the limitation of what the current user can view) ? Nir > Self Service - CRUD Sub Tenant > -- > > Key: TC-217 > URL: https://issues.apache.org/jira/browse/TC-217 > Project: Traffic Control > Issue Type: New Feature > Components: Traffic Ops, Traffic Ops API >Reporter: Ashish Timilsina > > Allow users to CRUD sub tenants below their tenant level or below any > sub-tenant level they choose. Default would be directly below the current > tenant value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TC-217) Self Service - CRUD Sub Tenant
[ https://issues.apache.org/jira/browse/TC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972417#comment-15972417 ] Nir Sopher commented on TC-217: --- Hi, I believe we need to distinguish between the 2 terminologies: "descendent-tenants", and "allowed-tenants". A tenants has "descendent-tenants", all the tenants beneath it in the hierarchy. A user has its "allowed-tenants" - tenants he can view and manage. Currently, the to terms are closely related - the "allowed-tenants" of a user are the "descendent-tenants" of the user's tenant. But this is not necessarily the case. There are a few futuristic examples for users need to be able to view tenants not in his own tenant hierarchy. For example, when we have multiple ISPs in the TC, none of which can be "root" tenant, but the users of this tenants need to be able to view "org-tenants" in order to work with their delivery services. Therefore we suggested that: api/1.2/tenants - will show all tenants view-able to the current user. api/1.2/tenants/:id/subtenants - will show all "tenants" decendent to the specified one (still, under the limitation of what the current user can view) Do we need additionally api/1.2/users/:id/tenants - get all the tenants viewable to the specified user (still, under the limitation of what the current user can view) ? Nir > Self Service - CRUD Sub Tenant > -- > > Key: TC-217 > URL: https://issues.apache.org/jira/browse/TC-217 > Project: Traffic Control > Issue Type: New Feature > Components: Traffic Ops, Traffic Ops API >Reporter: Ashish Timilsina > > Allow users to CRUD sub tenants below their tenant level or below any > sub-tenant level they choose. Default would be directly below the current > tenant value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (TC-217) Self Service - CRUD Sub Tenant
[ https://issues.apache.org/jira/browse/TC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954994#comment-15954994 ] Nir Sopher edited comment on TC-217 at 4/5/17 8:59 AM: --- Further thinking of the issue I would like to revise the earlier suggestion I placed. In this JIRA you first request to "Allow users to CRUD sub tenants below their tenant". I believe what you practically need is a way to get the list of tenants the user may access. The fact that these tenants are descendants of the user's tenant is just a detail. This may change in the future. So I would like to suggest the following API: 1. api/1.2/users/:id/tenants - get all the tenants the user with the given id may access 2. api/1.2/user/current/tenants - get all the tenants the current user may access Additionally you request to have the list of tenants "below any sub-tenant level they choose". For this purpose I suggest the following API: 3. api/1.2/tenants/:id/subtenants - get the list of tenants descendant to the tenant with the id "id". -- The provided list is subject to the current allowed view -- "current" is not supported as an "id" Ryan/Ashish, please let me know if this API meets your needs. Thanks, Nir was (Author: nirsopher): Further thinking of the issue I would like to revise the earlier suggestion I placed. In this JIRA you first request to "Allow users to CRUD sub tenants below their tenant". I believe what you practically need is a way to get the list of tenants the user may access. The fact that these tenants are descendants of the user's tenant is just a detail. This may change in the future. So I would like to suggest the following API: 1. api/1.2/user/:id/tenants - get all the tenants the user with the given id may access 2. api/1.2/user/current/tenants - get all the tenants the current user may access Additionally you request to have the list of tenants "below any sub-tenant level they choose". For this purpose I suggest the following API: 3. api/1.2/tenants/:id/subtenants - get the list of tenants descendant to the tenant with the id "id". -- The provided list is subject to the current allowed view -- "current" is not supported as an "id" Ryan/Ashish, please let me know if this API meets your needs. Thanks, Nir > Self Service - CRUD Sub Tenant > -- > > Key: TC-217 > URL: https://issues.apache.org/jira/browse/TC-217 > Project: Traffic Control > Issue Type: New Feature > Components: Traffic Ops, Traffic Ops API >Reporter: Ashish Timilsina > > Allow users to CRUD sub tenants below their tenant level or below any > sub-tenant level they choose. Default would be directly below the current > tenant value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (TC-217) Self Service - CRUD Sub Tenant
[ https://issues.apache.org/jira/browse/TC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954994#comment-15954994 ] Nir Sopher edited comment on TC-217 at 4/5/17 8:57 AM: --- Further thinking of the issue I would like to revise the earlier suggestion I placed. In this JIRA you first request to "Allow users to CRUD sub tenants below their tenant". I believe what you practically need is a way to get the list of tenants the user may access. The fact that these tenants are descendants of the user's tenant is just a detail. This may change in the future. So I would like to suggest the following API: 1. api/1.2/user/:id/tenants - get all the tenants the user with the given id may access 2. api/1.2/user/current/tenants - get all the tenants the current user may access Additionally you request to have the list of tenants "below any sub-tenant level they choose". For this purpose I suggest the following API: 3. api/1.2/tenants/:id/subtenants - get the list of tenants descendant to the tenant with the id "id". -- The provided list is subject to the current allowed view -- "current" is not supported as an "id" Ryan/Ashish, please let me know if this API meets your needs. Thanks, Nir was (Author: nirsopher): Further thinking of the issue I would like to revise the earlier suggestion I placed. In this JIRA you first request to "Allow users to CRUD sub tenants below their tenant". I believe what you practically need is a way to get the list of tenants the user may access. The fact that these tenants are descendants of the user's tenant is just a detail. This may change in the future. So I would like to suggest the following API: 1. api/1.2/tenants/:id/tenants - get all the tenants the user with the given id may access 2. api/1.2/tenants/current/tenants - get all the tenants the current user may access Additionally you request to have the list of tenants "below any sub-tenant level they choose". For this purpose I suggest the following API: 3. api/1.2/tenants/:id/subtenants - get the list of tenants descendant to the tenant with the id "id". -- The provided list is subject to the current allowed view -- "current" is not supported as an "id" Ryan/Ashish, please let me know if this API meets your needs. Thanks, Nir > Self Service - CRUD Sub Tenant > -- > > Key: TC-217 > URL: https://issues.apache.org/jira/browse/TC-217 > Project: Traffic Control > Issue Type: New Feature > Components: Traffic Ops, Traffic Ops API >Reporter: Ashish Timilsina > > Allow users to CRUD sub tenants below their tenant level or below any > sub-tenant level they choose. Default would be directly below the current > tenant value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TC-217) Self Service - CRUD Sub Tenant
[ https://issues.apache.org/jira/browse/TC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15955009#comment-15955009 ] Nir Sopher commented on TC-217: --- Ryan, Per your comment, please see my comments and edits to https://cwiki.apache.org/confluence/display/TC/Self-Service Thanks, Nir > Self Service - CRUD Sub Tenant > -- > > Key: TC-217 > URL: https://issues.apache.org/jira/browse/TC-217 > Project: Traffic Control > Issue Type: New Feature > Components: Traffic Ops, Traffic Ops API >Reporter: Ashish Timilsina > > Allow users to CRUD sub tenants below their tenant level or below any > sub-tenant level they choose. Default would be directly below the current > tenant value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TC-217) Self Service - CRUD Sub Tenant
[ https://issues.apache.org/jira/browse/TC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954994#comment-15954994 ] Nir Sopher commented on TC-217: --- Further thinking of the issue I would like to revise the earlier suggestion I placed. In this JIRA you first request to "Allow users to CRUD sub tenants below their tenant". I believe what you practically need is a way to get the list of tenants the user may access. The fact that these tenants are descendants of the user's tenant is just a detail. This may change in the future. So I would like to suggest the following API: 1. api/1.2/tenants/:id/tenants - get all the tenants the user with the given id may access 2. api/1.2/tenants/current/tenants - get all the tenants the current user may access Additionally you request to have the list of tenants "below any sub-tenant level they choose". For this purpose I suggest the following API: 3. api/1.2/tenants/:id/subtenants - get the list of tenants descendant to the tenant with the id "id". -- The provided list is subject to the current allowed view -- "current" is not supported as an "id" Ryan/Ashish, please let me know if this API meets your needs. Thanks, Nir > Self Service - CRUD Sub Tenant > -- > > Key: TC-217 > URL: https://issues.apache.org/jira/browse/TC-217 > Project: Traffic Control > Issue Type: New Feature > Components: Traffic Ops, Traffic Ops API >Reporter: Ashish Timilsina > > Allow users to CRUD sub tenants below their tenant level or below any > sub-tenant level they choose. Default would be directly below the current > tenant value. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TC-217) Self Service - CRUD Sub Tenant
[
https://issues.apache.org/jira/browse/TC-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15944602#comment-15944602
]
Nir Sopher commented on TC-217:
---
Hi,
Please let me know if the below satisfy you need:
Adding an api whose output is identical to the standard tenants list api
("api/1.2/tenants"), but just list the relevant tenants?
We can put it under "api/1.2/tenants/:id/subtenants".
:id can be a tenant index, or "current" (which means "the tenant of the current
user").
Nir
> Self Service - CRUD Sub Tenant
> --
>
> Key: TC-217
> URL: https://issues.apache.org/jira/browse/TC-217
> Project: Traffic Control
> Issue Type: New Feature
> Components: Traffic Ops, Traffic Ops API
>Reporter: Ashish Timilsina
>
> Allow users to CRUD sub tenants below their tenant level or below any
> sub-tenant level they choose. Default would be directly below the current
> tenant value.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TC-215) SSL Automate Standard Cert Generation and Application
[ https://issues.apache.org/jira/browse/TC-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15944597#comment-15944597 ] Nir Sopher commented on TC-215: --- Please note that the solution proposed in TC-55 practically allows you to use the same certificate for more than one delivery service. I would suggest it would be also push forward. Nir > SSL Automate Standard Cert Generation and Application > - > > Key: TC-215 > URL: https://issues.apache.org/jira/browse/TC-215 > Project: Traffic Control > Issue Type: New Feature > Components: Traffic Ops, Traffic Ops API >Reporter: Ashish Timilsina > Labels: feature > > It currently takes 2-3 business days to generate and apply an SSL cert. This > is a manual process for several departments which means it often gets slowed > down due to hand offs. We would like to automate the SSL cert generation and > application process. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TC-184) Tenant Hierarchy
[ https://issues.apache.org/jira/browse/TC-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926224#comment-15926224 ] Nir Sopher commented on TC-184: --- Hi Ryan, I'm currently working on a PR focusing on items 1-4 of the JIRA requirements. May I make my PR and refer them to this JIRA? Thanks, Nir > Tenant Hierarchy > > > Key: TC-184 > URL: https://issues.apache.org/jira/browse/TC-184 > Project: Traffic Control > Issue Type: New Feature > Components: Traffic Ops >Reporter: Ryan Durfey > Labels: Access, Tenancy > > Design under discussion here: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68715910 > The requirements below are seed requirements and final design guidance should > defer to the evolving wiki page discussion referenced above. > Overview > The goal of this system is to create a hierarchical tenancy system which is > very simple to understand and administer and is highly expandable so that > large organizations with many subsidiaries have the flexibility to create > child-tenants to their liking. > General Seed Requirements > 1. Provide a structure to create a hierarchy of Tenants where each Tenant has > a single parent-Tenant and can have multiple child-Tenants > 2. Provide the ability to group multiple Delivery Services, Users, and child- > Tenants under each Tenant > 3. Provide the ability to create at least 10 child-Tenant layers within the > system > 4. Make it easy to assign a User to a single Tenant so that they inherit > their permissions to all child-Tenants and Delivery Services. > 5. Adding child-Tenants or Delivery Services anywhere in an existing tenant > hierarchy does not require re-assigning users. Users inherit pre-defined > permissions to new tenants and services added below their assigned layer in > the tenancy tree. > 6. Allow Users to be assigned multiple Tenants, each with different Roles. > While a user would inherit their access to all services and child Tenants > below them, they may need more restrictive access further up the Tenant > hierarchy or they may want different access to another branch of the tenant > tree. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] (TC-104) httpsPort key is missing in the CRConfig contentRouters section for 1.8
Title: Message Title Nir Sopher commented on TC-104 Re: httpsPort key is missing in the CRConfig contentRouters section for 1.8 Is this issue already closed in master? Examining the crconfig it seems like it is resolved, unless there is a specific usecase causing the variable to be omitted. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] [Created] (TC-121) Parametrized traffic-server configuration
Nir Sopher created TC-121: - Summary: Parametrized traffic-server configuration Key: TC-121 URL: https://issues.apache.org/jira/browse/TC-121 Project: Traffic Control Issue Type: Improvement Components: Traffic Ops Reporter: Nir Sopher Priority: Minor We would like to allow an individual traffic-server configuration, dervied from its profile as well as its specific configuration. For example, set the traffic-server to listen the configured IP by setting proxy-local-incoming-ip-to-bind value. In order to do so, variables should be embedded within profile variables values. For example: __CACHE_IPV4__ and __CACHE_IPV6__ Future variables to discuss: http/s ports, hostname, domain -- This message was sent by Atlassian JIRA (v6.3.4#6332)
