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

[Dan Kirkwood (JIRA)]

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

Dan Kirkwood resolved TC-355.
-
Resolution: Fixed

Looks like this was resolved...

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



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

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

[Dan Kirkwood (JIRA)]

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

Dan Kirkwood updated TC-266:

Fix Version/s: (was: 2.1.0)
   2.2.0

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



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

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

[Dan Kirkwood (JIRA)]

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

Dan Kirkwood updated TC-242:

Fix Version/s: (was: 2.1.0)
   2.2.0

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



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

[jira] [Updated] (TC-191) Steering DS API should use standard response codes as defined in API guidelines

[Dan Kirkwood (JIRA)]

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

Dan Kirkwood updated TC-191:

Fix Version/s: (was: 2.1.0)
   2.2.0

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

[GitHub] incubator-trafficcontrol issue #781: WIP - Adding contact information to Ten...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/33/



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

[jira] [Updated] (TC-472) traffic_ops/experimental - failure to assign servers to new Delivery Service

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-472:
---
Affects Version/s: 2.1.0

> traffic_ops/experimental - failure to assign servers to new Delivery Service
> 
>
> Key: TC-472
> URL: https://issues.apache.org/jira/browse/TC-472
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Jason Tucker
>Priority: Minor
>
> While using the new UI, I was unable to assign servers to a newly-created DS. 
> After submitting the change, no servers were linked. No error apparent when 
> submitting. Tried multiple times with same results.
> Browser: chrome 58.0.3029.110



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

[jira] [Closed] (TC-486) Add steering role to steering apis

[Hank Beatty (JIRA)]

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

Hank Beatty closed TC-486.
--

fixed by commit 28fb076fba5f705e4bf34dcb8ffd4dc6c6c8588a

> 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-486) Add steering role to steering apis

[Hank Beatty (JIRA)]

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

Hank Beatty resolved TC-486.

   Resolution: Fixed
Fix Version/s: 2.1.0

fixed by commit 28fb076fba5f705e4bf34dcb8ffd4dc6c6c8588a

> 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] [Commented] (TC-486) Add steering role to steering apis

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-486:


this was merged into master by 28fb076fba5f705e4bf34dcb8ffd4dc6c6c8588a

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

[GitHub] incubator-trafficcontrol issue #729: Traffic Ops Golang Incremental Rewrite ...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/32/



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

[GitHub] incubator-trafficcontrol issue #729: Traffic Ops Golang Incremental Rewrite ...

[dewrich]

Github user dewrich commented on the issue:

https://github.com/apache/incubator-trafficcontrol/pull/729
  
"test this please"


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

[jira] [Updated] (TC-499) Traffic Portal logging should be consistent with other TC applications

[David Neuman (JIRA)]

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

David Neuman updated TC-499:

Issue Type: Improvement  (was: Bug)

> Traffic Portal logging should be consistent with other TC applications
> --
>
> Key: TC-499
> URL: https://issues.apache.org/jira/browse/TC-499
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Portal
>Affects Versions: 2.1.0
>Reporter: David Neuman
>
> Currently, Traffic Portal's logging is different from other TC components.  
> It does not contain a log level or a timestamp.  We should make the logging 
> consistent with other TC components so that users can easily discern what is 
> going on and when it happened.
> Example of the current logging (these messages were over several hours): 
> {quote}
> Error: ENOENT: no such file or directory, open '/etc/pki/tls/private/ca.crt'
> at Error (native)
> at Object.fs.openSync (fs.js:641:18)
> at Object.fs.readFileSync (fs.js:509:33)
> at Object. (/opt/traffic_portal/server.js:148:29)
> at Module._compile (module.js:570:32)
> at Object.Module._extensions..js (module.js:579:10)
> at Module.load (module.js:487:32)
> at tryModuleLoad (module.js:446:12)
> at Function.Module._load (module.js:438:3)
> at Module.runMain (module.js:604:10)
> error: Forever detected script exited with code: 1
> error: Script restart attempt #116
> Traffic Portal Port : 80
> Traffic Portal SSL Port : 443
> error: Forever detected script was killed by signal: SIGKILL
> Traffic Portal Port : 80
> Traffic Portal SSL Port : 443
> error: Forever detected script was killed by signal: SIGKILL
> Traffic Portal Port : 80
> Traffic Portal SSL Port : 443
> {quote}



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

[jira] [Updated] (TC-498) TO API - when updating current user, full name is required

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-498:
---
Affects 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
>
> 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] [Updated] (TC-499) Traffic Portal logging should be consistent with other TC applications

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-499:
---
Affects Version/s: 2.1.0

> Traffic Portal logging should be consistent with other TC applications
> --
>
> Key: TC-499
> URL: https://issues.apache.org/jira/browse/TC-499
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Portal
>Affects Versions: 2.1.0
>Reporter: David Neuman
>
> Currently, Traffic Portal's logging is different from other TC components.  
> It does not contain a log level or a timestamp.  We should make the logging 
> consistent with other TC components so that users can easily discern what is 
> going on and when it happened.
> Example of the current logging (these messages were over several hours): 
> {quote}
> Error: ENOENT: no such file or directory, open '/etc/pki/tls/private/ca.crt'
> at Error (native)
> at Object.fs.openSync (fs.js:641:18)
> at Object.fs.readFileSync (fs.js:509:33)
> at Object. (/opt/traffic_portal/server.js:148:29)
> at Module._compile (module.js:570:32)
> at Object.Module._extensions..js (module.js:579:10)
> at Module.load (module.js:487:32)
> at tryModuleLoad (module.js:446:12)
> at Function.Module._load (module.js:438:3)
> at Module.runMain (module.js:604:10)
> error: Forever detected script exited with code: 1
> error: Script restart attempt #116
> Traffic Portal Port : 80
> Traffic Portal SSL Port : 443
> error: Forever detected script was killed by signal: SIGKILL
> Traffic Portal Port : 80
> Traffic Portal SSL Port : 443
> error: Forever detected script was killed by signal: SIGKILL
> Traffic Portal Port : 80
> Traffic Portal SSL Port : 443
> {quote}



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

[jira] [Commented] (TC-501) TPv2 installation - better defaults are required

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-501:


[~mitchell...@apache.org] Is this something that needs to be fixed in 2.1.0 or 
can it wait until 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] [Updated] (TC-502) ORT fails to handle non-file arguments

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-502:
---
Affects Version/s: 2.1.0

> ORT fails to handle non-file arguments
> --
>
> Key: TC-502
> URL: https://issues.apache.org/jira/browse/TC-502
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops ORT
>Affects Versions: 2.1.0
>Reporter: Chris Lemmons
>
> ORT currently processes the parameters of all plugins on the remap.config 
> line as though they were files. However, parameters to `cachekey.config` are 
> parsed as parameters directly on the remap line. So, for example, if you have 
> a remap line that contains something like this:
> {{@plugin=cachekey.so @pparam=--remove-path=true}}
> That will cause ORT to attempt to load a config file named 
> {{--remove-path=true}}. ORT fails to accomplish this in several ways and 
> produces a variety of errors:
> DEBUG Starting processing of config file: --remove-path=true
> WARN --remove-path=true is being processed with an unknown service
> {code:none}
> INFO:  Start processing config file: --remove-path=true 
> Use of uninitialized value in concatenation (.) or string at 
> /opt/ort/traffic_ops_ort.pl line 2515.
> Use of uninitialized value $dir in -d at /opt/ort/traffic_ops_ort.pl line 645.
> Use of uninitialized value $dir in concatenation (.) or string at 
> /opt/ort/traffic_ops_ort.pl line 648.
> /bin/mkdir: missing operand
> Try '/bin/mkdir --help' for more information.
> Use of uninitialized value $dir in pattern match (m//) at 
> /opt/ort/traffic_ops_ort.pl line 649.
> Use of uninitialized value $dir in pattern match (m//) at 
> /opt/ort/traffic_ops_ort.pl line 653.
> Use of uninitialized value $dir in concatenation (.) or string at 
> /opt/ort/traffic_ops_ort.pl line 657.
> DEBUG Directory created: .
> Use of uninitialized value $result in pattern match (m//) at 
> /opt/ort/traffic_ops_ort.pl line 2482.
> Use of uninitialized value $size in numeric eq (==) at 
> /opt/ort/traffic_ops_ort.pl line 2488.
> Use of uninitialized value $url in concatenation (.) or string at 
> /opt/ort/traffic_ops_ort.pl line 2489.
> ERROR URL:  returned empty!
> {code}
> ORT should probably skip "files" that start with {{-}}.



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

[jira] [Updated] (TC-503) Traffic Ops ORT Fails with Chunked Encoding

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-503:
---
Affects Version/s: 2.1.0

> Traffic Ops ORT Fails with Chunked Encoding
> ---
>
> Key: TC-503
> URL: https://issues.apache.org/jira/browse/TC-503
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops ORT
>Affects Versions: 2.1.0
>Reporter: Robert Butts
>Assignee: Robert Butts
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> ORT fails if no 'Content-Length' header exists.
> Content-Length MAY be omitted per HTTP/1.1 RFC 7230, and in fact MUST NOT be 
> included with a 'Transfer-Encoding: Chunked' header, which MUST be accepted 
> by clients.
> So far, we've just been lucky Perl/Mojolicious Traffic Ops doesn't happen to 
> send Chunked encodings to ORT. But the spec requires clients accept it, ORT 
> is in violation of HTTP/1.1. 
> Further, the upcoming Golang Traffic Ops sends Chunked encoding, and there's 
> no reasonable way in Go to prevent it. There's no HTTP-compliant way to 
> instruct the server not to send Chunked encoding either, since clients are 
> required to accept it. The right solution here is to fix ORT to accept 
> Chunked encoding, without Content-Length.
> It appears ORT only refuses it as a safety check, and doesn't actually need 
> it for anything. Should be a simple fix.



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

[jira] [Commented] (TC-506) Traffic Ops - SSL Cert Expiration Monitoring for Active Services

[Hank Beatty (JIRA)]

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

Hank Beatty commented on TC-506:


This isn't a bug. This is an enhancement. Changing status.

> Traffic Ops - SSL Cert Expiration Monitoring for Active Services
> 
>
> Key: TC-506
> URL: https://issues.apache.org/jira/browse/TC-506
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>  Labels: Expiration, SSL, TLS
>
> With all services moving towards SSL there will be a constant battle to keep 
> SSL certificates up to date for active services.  Traffic Ops should 
> incorporate an internal monitor for upcoming expirations based on the actual 
> cert source of record.  This could be a part of the delivery service 
> configuration data and would also be useful to customers to examine when 
> certs expire.
> 1. Record or read SSL cert expiration and put into configuration data
> 2. Allow users access to this data through the API
> 3. Provide a monitor that runs on a cron to look for certs that expire soon.
> 4. Alert root operators daily on upcoming expirations



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

[jira] [Updated] (TC-506) Traffic Ops - SSL Cert Expiration Monitoring for Active Services

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-506:
---
Issue Type: Improvement  (was: Bug)

> Traffic Ops - SSL Cert Expiration Monitoring for Active Services
> 
>
> Key: TC-506
> URL: https://issues.apache.org/jira/browse/TC-506
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>  Labels: Expiration, SSL, TLS
>
> With all services moving towards SSL there will be a constant battle to keep 
> SSL certificates up to date for active services.  Traffic Ops should 
> incorporate an internal monitor for upcoming expirations based on the actual 
> cert source of record.  This could be a part of the delivery service 
> configuration data and would also be useful to customers to examine when 
> certs expire.
> 1. Record or read SSL cert expiration and put into configuration data
> 2. Allow users access to this data through the API
> 3. Provide a monitor that runs on a cron to look for certs that expire soon.
> 4. Alert root operators daily on upcoming expirations



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

[jira] [Updated] (TC-506) Traffic Ops - SSL Cert Expiration Monitoring for Active Services

[Hank Beatty (JIRA)]

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

Hank Beatty updated TC-506:
---
Affects Version/s: 2.1.0

> Traffic Ops - SSL Cert Expiration Monitoring for Active Services
> 
>
> Key: TC-506
> URL: https://issues.apache.org/jira/browse/TC-506
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Ryan Durfey
>  Labels: Expiration, SSL, TLS
>
> With all services moving towards SSL there will be a constant battle to keep 
> SSL certificates up to date for active services.  Traffic Ops should 
> incorporate an internal monitor for upcoming expirations based on the actual 
> cert source of record.  This could be a part of the delivery service 
> configuration data and would also be useful to customers to examine when 
> certs expire.
> 1. Record or read SSL cert expiration and put into configuration data
> 2. Allow users access to this data through the API
> 3. Provide a monitor that runs on a cron to look for certs that expire soon.
> 4. Alert root operators daily on upcoming expirations



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

[jira] [Created] (TC-506) Traffic Ops - SSL Cert Expiration Monitoring for Active Services

[Ryan Durfey (JIRA)]

Ryan Durfey created TC-506:
--

 Summary: Traffic Ops - SSL Cert Expiration Monitoring for Active 
Services
 Key: TC-506
 URL: https://issues.apache.org/jira/browse/TC-506
 Project: Traffic Control
  Issue Type: Bug
  Components: Traffic Ops
Reporter: Ryan Durfey


With all services moving towards SSL there will be a constant battle to keep 
SSL certificates up to date for active services.  Traffic Ops should 
incorporate an internal monitor for upcoming expirations based on the actual 
cert source of record.  This could be a part of the delivery service 
configuration data and would also be useful to customers to examine when certs 
expire.

1. Record or read SSL cert expiration and put into configuration data
2. Allow users access to this data through the API
3. Provide a monitor that runs on a cron to look for certs that expire soon.
4. Alert root operators daily on upcoming expirations



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/30/



> Add ability to copy url_sig keys from one DS to another GH #1540
> 
>
> Key: TC-336
> URL: https://issues.apache.org/jira/browse/TC-336
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Vault
>Reporter: Dewayne Richardson
>Assignee: Dylan Volz
>Priority: Minor
>  Labels: keys, url_signing
>
> There are some cases where we want to use the same URL sig keys for multiple 
> delivery services. Currently this is handled by using cURL and other manual 
> processes. Traffic Ops should support the ability to copy url sig keys from 
> one DS to another. When this happens Traffic Ops should also create the 
> necessary parameters for the target DS so that URL signing works.



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

[GitHub] incubator-trafficcontrol issue #790: [TC-336] build ui for managing url sig ...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/30/



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

[jira] [Commented] (TC-505) LDAP only users are greeted with a 404 for all UI / API routes

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/29/



> 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] [Commented] (TC-505) LDAP only users are greeted with a 404 for all UI / API routes

[ASF GitHub Bot (JIRA)]

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

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

GitHub user mitchell852 opened a pull request:

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

[TC-505] - throws 403 (rather than 404) if user is ldap-only (has no user 
entry …

…in tm_user table)

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

$ git pull https://github.com/mitchell852/incubator-trafficcontrol 
tc-505-ldap-only-403

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

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

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

This closes #793


commit bff78e0e6f96acad1341bb449e119846d187be2d
Author: Jeremy Mitchell 
Date:   2017-08-09T17:33:21Z

throws 403 (rather than 404) if user is ldap-only (has no user entry in 
tm_user table)




> 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] [Closed] (TC-450) Traffic Ops API Rewrite: Unit Testing approach

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson closed TC-450.
-
Resolution: Fixed

Changed Fixed in Version

> Traffic Ops API Rewrite: Unit Testing approach
> --
>
> Key: TC-450
> URL: https://issues.apache.org/jira/browse/TC-450
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
> Fix For: 2.2.0
>
>
> Work through how to build a Unit Tests against the Golang modules, Database 
> Code in a consistent fashion



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

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

[Dan Kirkwood (JIRA)]

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

Dan Kirkwood reassigned TC-374:
---

Assignee: Dan Kirkwood

> `systemctl stop traffic_ops` does not kill all processes
> 
>
> Key: TC-374
> URL: https://issues.apache.org/jira/browse/TC-374
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>Assignee: Dan Kirkwood
>  Labels: systemctl
> Fix For: 2.1.0
>
>
> not sure why it gets in this state,  but traffic_ops processes sometimes get 
> in a state where the parent process is the root (1) for many of the 
> script/cdn workers.   The init.d script doesn't stop them because they don't 
> match the pid in `/var/run/traffic_ops.pid`.
> This needs to be more robust.
> Example:   on my test VM,  if I run this,  I see multiple parent processes:
> {quote}
>  ps -ef | grep script/cdn|grep -v root | awk '\{print $3\}'  | sort -u
>  1
>  22713
>  29306
> {quote}



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

[jira] [Updated] (TC-450) Traffic Ops API Rewrite: Unit Testing approach

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson updated TC-450:
--
Fix Version/s: (was: 2.1.0)

> Traffic Ops API Rewrite: Unit Testing approach
> --
>
> Key: TC-450
> URL: https://issues.apache.org/jira/browse/TC-450
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>
> Work through how to build a Unit Tests against the Golang modules, Database 
> Code in a consistent fashion



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

[jira] [Reopened] (TC-450) Traffic Ops API Rewrite: Unit Testing approach

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson reopened TC-450:
---

> Traffic Ops API Rewrite: Unit Testing approach
> --
>
> Key: TC-450
> URL: https://issues.apache.org/jira/browse/TC-450
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
> Fix For: 2.1.0
>
>
> Work through how to build a Unit Tests against the Golang modules, Database 
> Code in a consistent fashion



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

[jira] [Closed] (TC-450) Traffic Ops API Rewrite: Unit Testing approach

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson closed TC-450.
-
   Resolution: Fixed
Fix Version/s: 2.1.0

Completed with https://github.com/apache/incubator-trafficcontrol/pull/729

> Traffic Ops API Rewrite: Unit Testing approach
> --
>
> Key: TC-450
> URL: https://issues.apache.org/jira/browse/TC-450
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
> Fix For: 2.1.0
>
>
> Work through how to build a Unit Tests against the Golang modules, Database 
> Code in a consistent fashion



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

[jira] [Closed] (TC-451) Traffic Ops API Rewrite: Developer's Guide - Documentation

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson closed TC-451.
-
Resolution: Fixed

Completed with https://github.com/apache/incubator-trafficcontrol/pull/729

> Traffic Ops API Rewrite: Developer's Guide - Documentation
> --
>
> Key: TC-451
> URL: https://issues.apache.org/jira/browse/TC-451
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>
> Documentation (Developer's Guide) on how to build a new Golang endpoint



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

[jira] [Closed] (TC-449) Traffic Ops API Rewrite: Implement logging wrapper

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson closed TC-449.
-
Resolution: Fixed

Completed with https://github.com/apache/incubator-trafficcontrol/pull/729

> Traffic Ops API Rewrite: Implement logging wrapper
> --
>
> Key: TC-449
> URL: https://issues.apache.org/jira/browse/TC-449
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>
> Build a consistent wrapper for the access.log and the traffic_ops.log



--
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 (JIRA)]

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] [Closed] (TC-381) postinstall errors if "secrets" is missing from cdn.conf

[Dan Kirkwood (JIRA)]

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

Dan Kirkwood closed TC-381.
---
   Resolution: Fixed
Fix Version/s: 2.1.0

Hank fixed this back in June -- already in 2.1 branch

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



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

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

[Dan Kirkwood (JIRA)]

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

Dan Kirkwood reassigned TC-381:
---

Assignee: Hank Beatty  (was: Dan Kirkwood)

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



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

[jira] [Commented] (TC-504) TPv2 - delivery service globalMaxMbps and globalMaxTps need to be verified as INT

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/28/



> 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] [Assigned] (TC-381) postinstall errors if "secrets" is missing from cdn.conf

[Dan Kirkwood (JIRA)]

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

Dan Kirkwood reassigned TC-381:
---

Assignee: Dan Kirkwood

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



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

[GitHub] incubator-trafficcontrol issue #792: [Backport] [TC-504] - fixes number vali...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/28/



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

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

[Dylan Volz (JIRA)]

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

Dylan Volz resolved TC-336.
---
Resolution: Fixed

> Add ability to copy url_sig keys from one DS to another GH #1540
> 
>
> Key: TC-336
> URL: https://issues.apache.org/jira/browse/TC-336
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops, Traffic Vault
>Reporter: Dewayne Richardson
>Assignee: Dylan Volz
>Priority: Minor
>  Labels: keys, url_signing
>
> There are some cases where we want to use the same URL sig keys for multiple 
> delivery services. Currently this is handled by using cURL and other manual 
> processes. Traffic Ops should support the ability to copy url sig keys from 
> one DS to another. When this happens Traffic Ops should also create the 
> necessary parameters for the target DS so that URL signing works.



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

[GitHub] incubator-trafficcontrol pull request #792: [Backport] [TC-504] - fixes numb...

[mitchell852]

GitHub user mitchell852 opened a pull request:

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

[Backport] [TC-504] - fixes number validation on global max settings

(cherry picked from commit 8603bc83dfe9b667af54f9101028740940bac86f)

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

$ git pull https://github.com/mitchell852/incubator-trafficcontrol 2.1.x

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

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

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

This closes #792


commit a376bc0670ea137ceef7da7a6e26394600fc77b3
Author: Jeremy Mitchell 
Date:   2017-08-09T14:58:10Z

fixes number validation on global max settings

(cherry picked from commit 8603bc83dfe9b667af54f9101028740940bac86f)




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

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

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson updated TC-283:
--
Issue Type: Improvement  (was: Bug)

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



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

[jira] [Updated] (TC-445) Traffic Ops API Rewrite: Implement /api/1.2/users with MojoCookie+Capabilities

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson updated TC-445:
--
Issue Type: New Feature  (was: Improvement)

> Traffic Ops API Rewrite: Implement /api/1.2/users with MojoCookie+Capabilities
> --
>
> Key: TC-445
> URL: https://issues.apache.org/jira/browse/TC-445
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>
> Implement the first TO Golang endpoint using the MojoCookies+Capabilities



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

[jira] [Resolved] (TC-148) GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns pointer to Hash

[Dylan Volz (JIRA)]

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

Dylan Volz resolved TC-148.
---
Resolution: Fixed

> GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns pointer to Hash
> --
>
> Key: TC-148
> URL: https://issues.apache.org/jira/browse/TC-148
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops, Traffic Ops API
>Reporter: Jeremy Mitchell
>Assignee: Dylan Volz
>Priority: Minor
>  Labels: api_deliveryservices
>
> GET /api/deliveryservices/xmlId/:xmlId/urlkeys returns, for example:
> {
> response: "HTTP::Response=HASH(0x6f9f018)"
> }
> instead of the actual json hash/object.



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

[jira] [Resolved] (TC-504) TPv2 - delivery service globalMaxMbps and globalMaxTps need to be verified as INT

[Jeremy Mitchell (JIRA)]

 [ 
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] [Resolved] (TC-247) Upgrading Traffic Ops via yum, goose is failing to execute

[Robert Scrimo (JIRA)]

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

Robert Scrimo resolved TC-247.
--
   Resolution: Fixed
Fix Version/s: 2.1.0

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

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

[Robert Scrimo (JIRA)]

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

Robert Scrimo closed TC-247.

Assignee: Robert Scrimo

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

[jira] [Commented] (TC-504) TPv2 - delivery service globalMaxMbps and globalMaxTps need to be verified as INT

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


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

[GitHub] incubator-trafficcontrol pull request #791: [TC-504] - fixes number validati...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[jira] [Updated] (TC-366) Improve misc/release.pl to do more release management tasks

[Eric Friedrich (JIRA)]

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

Eric Friedrich updated TC-366:
--
Affects Version/s: 2.1.0

> Improve misc/release.pl to do more release management tasks
> ---
>
> Key: TC-366
> URL: https://issues.apache.org/jira/browse/TC-366
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Release
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Eric Friedrich
>Priority: Minor
>  Labels: build, release.pl
>
> Today misc/release.pl does the following: 
> 1) Updates VERSION file
> 2) Creates and pushes a signed git tag
> It would be nice if misc/release.pl also did the following
> 1) Create release tarball by calling docker-compose 
> 2) Unpack release tarball and run docker-compose build. Verify RPMs are 
> built. 
> 2) Create gpg armormed sig by running `gpg --armor --detach-sig 
> incubator-trafficcontrol-.tgz`
> 2a) Verify signature with gpg --verify 
> incubator-trafficcontrol-.tgz.asc
> 3) Create MD5 and SHA512 signatures with:
> `md5sum incubator-trafficcontrol-.tgz > 
> incubator-trafficcontrol-.tgz.md5
> shasum -a512 incubator-trafficcontrol-.tgz > 
> incubator-trafficcontrol-.tgz.sha512`
> 3a) Check signatures with :
> `md5sum -c incubator-trafficcontrol-.tgz.md5
> shasum -c incubator-trafficcontrol-.tgz.sha512`



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

[jira] [Updated] (TC-296) ANY_MAP doesn't get applied to the mids

[Eric Friedrich (JIRA)]

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

Eric Friedrich updated TC-296:
--
Affects Version/s: 2.0.0
   2.1.0

> ANY_MAP doesn't get applied to the mids
> ---
>
> Key: TC-296
> URL: https://issues.apache.org/jira/browse/TC-296
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Eric Friedrich
>Priority: Minor
>  Labels: any_map, remap.conf
>
> Delivery services of type ANY_MAP only gets a line in remap.conf for caches 
> of type EDGE.
> https://github.com/Comcast/traffic_control/issues/740



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

[jira] [Closed] (TC-347) Docker Build for Portal fails with SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://rubygems.org/latest_specs.4.8.gz

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson closed TC-347.
-
Resolution: Cannot Reproduce
  Assignee: Dewayne Richardson

> Docker Build for Portal fails with SSL_connect returned=1 errno=0 state=SSLv3 
> read server certificate B: certificate verify failed 
> (https://rubygems.org/latest_specs.4.8.gz
> 
>
> Key: TC-347
> URL: https://issues.apache.org/jira/browse/TC-347
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Portal
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>  Labels: build, docker
>
> Attempting to build the rpms and the build fails at the Portal phase.
> ---
> Step 6/10 : RUN gem install compass
>  ---> Running in 5f883ef539c1
> ERROR:  Could not find a valid gem 'compass' (>= 0), here is why:
>   Unable to download data from https://rubygems.org/ - SSL_connect 
> returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify 
> failed (https://rubygems.org/latest_specs.4.8.gz)
> ERROR: Service 'traffic_portal_build' failed to build: The command '/bin/sh 
> -c gem install compass' returned a non-zero code: 2



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

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

[Dylan Volz (JIRA)]

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

Dylan Volz edited comment on TC-374 at 8/9/17 4:00 PM:
---

This means the processes were orphaned, and adopted by root (as expected) but 
then never waited on (reaped). I happened to have just read about a similar 
issue docker can have here: 
https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/.

Seems that hypnotoad (wrapping Mojo::Server::Prefork) should be handling this 
and it will require some digging, I think some tooling using 
http://mojolicious.org/perldoc/Mojo/Server/Prefork#reap
and http://mojolicious.org/perldoc/Mojo/Server/Prefork#spawn may help 
illuminate what is going on.


was (Author: dylan_volz):
This means the processes were orphaned, and adopted by root (as expected) but 
then never waited on (reaped). I happened to have just read about a similar 
issue docker can have here: 
https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/ 
that describes it in detail and perhaps a similar solution can be applied in 
our start up script.

> `systemctl stop traffic_ops` does not kill all processes
> 
>
> Key: TC-374
> URL: https://issues.apache.org/jira/browse/TC-374
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops
>Affects Versions: 2.1.0
>Reporter: Dan Kirkwood
>  Labels: systemctl
> Fix For: 2.1.0
>
>
> not sure why it gets in this state,  but traffic_ops processes sometimes get 
> in a state where the parent process is the root (1) for many of the 
> script/cdn workers.   The init.d script doesn't stop them because they don't 
> match the pid in `/var/run/traffic_ops.pid`.
> This needs to be more robust.
> Example:   on my test VM,  if I run this,  I see multiple parent processes:
> {quote}
>  ps -ef | grep script/cdn|grep -v root | awk '\{print $3\}'  | sort -u
>  1
>  22713
>  29306
> {quote}



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

[jira] [Closed] (TC-375) yum upgrade traffic_ops... can't find goose

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson closed TC-375.
-
Resolution: Fixed
  Assignee: Dewayne Richardson

This was fixed when we introduced /etc/profile.d/traffic_ops.sh to the rpm to 
set the global PATH accordingly

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



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

[jira] [Updated] (TC-445) Traffic Ops API Rewrite: Implement /api/1.2/users with MojoCookie+Capabilities

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson updated TC-445:
--
Issue Type: Improvement  (was: Bug)

> Traffic Ops API Rewrite: Implement /api/1.2/users with MojoCookie+Capabilities
> --
>
> Key: TC-445
> URL: https://issues.apache.org/jira/browse/TC-445
> Project: Traffic Control
>  Issue Type: Improvement
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>
> Implement the first TO Golang endpoint using the MojoCookies+Capabilities



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

[jira] [Closed] (TC-446) Traffic Ops API Rewrite: Testing PR #729 to use as the basis for TO rewrite

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson closed TC-446.
-
Resolution: Fixed
  Assignee: Dewayne Richardson

Complete:

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

> Traffic Ops API Rewrite: Testing PR #729 to use as the basis for TO rewrite
> ---
>
> Key: TC-446
> URL: https://issues.apache.org/jira/browse/TC-446
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
>




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

[jira] [Closed] (TC-447) Traffic Ops API Rewrite: Testing PR #729 to use as the basis for TO rewrite

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson closed TC-447.
-
   Resolution: Fixed
Fix Version/s: 2.1.0

Is complete, will be merging soon:

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

> Traffic Ops API Rewrite: Testing PR #729 to use as the basis for TO rewrite
> ---
>
> Key: TC-447
> URL: https://issues.apache.org/jira/browse/TC-447
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
> Fix For: 2.1.0
>
>
> PR https://github.com/apache/incubator-trafficcontrol/pull/729 is being 
> evaluated to determine how to move forward with the TO rewrite.  It has a 
> Mojolicious Cookie feature that will allow for services to be built that can 
> be authenticated against Mojolicious.  



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

[jira] [Updated] (TC-493) API documentation is not accurate for API Server Create and Update end-points

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson updated TC-493:
--
Priority: Minor  (was: Major)

> API documentation is not accurate for API Server Create and Update end-points
> -
>
> Key: TC-493
> URL: https://issues.apache.org/jira/browse/TC-493
> Project: Traffic Control
>  Issue Type: Bug
>  Components: Documentation, Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Robert Scrimo
>Priority: Minor
>
> API documentation is not accurate to functionality and lite on details for 
> API Server Create and Update end-points.
> Also, it may be a good idea to check over the entire Server API documentation 
> for accuracy while this work is being done.
> NOTE: Other versions of Traffic Ops may be affected.



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

[jira] [Closed] (TC-448) Traffic Ops API Rewrite: Config file organization

[Dewayne Richardson (JIRA)]

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

Dewayne Richardson closed TC-448.
-
   Resolution: Fixed
Fix Version/s: 2.1.0

See: https://github.com/apache/incubator-trafficcontrol/pull/729

> Traffic Ops API Rewrite: Config file organization
> -
>
> Key: TC-448
> URL: https://issues.apache.org/jira/browse/TC-448
> Project: Traffic Control
>  Issue Type: New Feature
>  Components: Traffic Ops API
>Affects Versions: 2.1.0
>Reporter: Dewayne Richardson
>Assignee: Dewayne Richardson
> Fix For: 2.1.0
>
>
> Write Golang logic to reuse the existing 
> /opt/traffic_ops/app/conf//*.conf files. As well as build a new 
> config file to support features the existing config files do not support.  
> Which might entail building reading the existing cdn.conf which is in a Perl 
> hash format.



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

[GitHub] incubator-trafficcontrol issue #791: [TC-504] - fixes number validation on g...

[asfgit]

Github user asfgit commented on the issue:

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

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/incubator-trafficcontrol-PR/27/



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

[jira] [Commented] (TC-504) TPv2 - delivery service globalMaxMbps and globalMaxTps need to be verified as INT

[ASF GitHub Bot (JIRA)]

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

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

GitHub user mitchell852 opened a pull request:

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

[TC-504] - fixes number validation on global max settings



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

$ git pull https://github.com/mitchell852/incubator-trafficcontrol 
tc-504-fixes-tp-validation-on-global-maxes

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

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

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

This closes #791


commit 8603bc83dfe9b667af54f9101028740940bac86f
Author: Jeremy Mitchell 
Date:   2017-08-09T14:58:10Z

fixes number validation on global max settings




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

[GitHub] incubator-trafficcontrol pull request #791: [TC-504] - fixes number validati...

[mitchell852]

GitHub user mitchell852 opened a pull request:

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

[TC-504] - fixes number validation on global max settings



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

$ git pull https://github.com/mitchell852/incubator-trafficcontrol 
tc-504-fixes-tp-validation-on-global-maxes

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

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

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

This closes #791


commit 8603bc83dfe9b667af54f9101028740940bac86f
Author: Jeremy Mitchell 
Date:   2017-08-09T14:58:10Z

fixes number validation on global max settings




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

[jira] [Resolved] (TC-428) Tenancy based access control - Delivery Service API

[Nir Sopher (JIRA)]

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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

 [ 
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

[Nir Sopher (JIRA)]

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