Bug 1677409

Summary: Worker Config Memory Threshold does not respect "string numbers"
Product: Red Hat CloudForms Management Engine Reporter: Satoe Imaishi <simaishi>
Component: ApplianceAssignee: Nick LaMuro <nlamuro>
Status: CLOSED ERRATA QA Contact: John Dupuy <jdupuy>
Severity: high Docs Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Priority: high    
Version: 5.10.0CC: abellott, dmetzger, obarenbo, simaishi
Target Milestone: GAKeywords: ZStream
Target Release: 5.10.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.10.1.2 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1677009 Environment:
Last Closed: 2019-03-06 09:50:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core Target Upstream Version:
Embargoed:
Bug Depends On: 1677009    
Bug Blocks:    

Comment 1 CFME Bot 2019-02-14 19:10:44 UTC
New commit detected on ManageIQ/manageiq/hammer:

https://github.com/ManageIQ/manageiq/commit/4568a21eb8cac0097b508d1c3f345c9005bd913a
commit 4568a21eb8cac0097b508d1c3f345c9005bd913a
Author:     Jason Frey <fryguy9>
AuthorDate: Wed Feb 13 13:00:57 2019 -0500
Commit:     Jason Frey <fryguy9>
CommitDate: Wed Feb 13 13:00:57 2019 -0500

    Merge pull request #18453 from NickLaMuro/handling_integer_strings_in_worker_settings

    [MiqWorker::worker_settings] Handle number strings

    (cherry picked from commit 2f897c5d50fdb89f4f8615c2f7d27c9b35c2690e)

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1677409

 app/models/miq_worker.rb | 8 +-
 spec/models/miq_worker_spec.rb | 35 +
 2 files changed, 42 insertions(+), 1 deletion(-)

Comment 2 John Dupuy 2019-02-25 15:01:47 UTC
Verified in CFME 5.10.1.2.20190219165527_7a4a22b. 

Steps of verification: 

1) Navigate to Configuration -> Advanced settings
2) Changed the memory threshold of e.g. "priority worker" to e.g. "1500000000" (with the quotes in the config yaml)
3) Observed the configuration sync in evm.log. I was able to see that the memory threshold was saved as: 1500000000 (without quotes)
4) Verified that in CFME 5.9.8.1 going through the same steps gives that the memory threshold is saved as: '1500000000' (with quotes)
5) Verified that the workers were not restarted in the process by watching them with the command "ps -f -p <PID>" where <PID> is the PID of the worker
6) I also checked with the "Generic Worker" and was able to see the same behavior. I am therefore marking this as verified. 


Let me know if I missed a better way to verify. Below is a snippet from evm.log showing the config sync. 

[----] I, [2019-02-25T09:51:13.753607 #15106:58af5c]  INFO 
-- : MIQ(MiqPriorityWorker::Runner#sync_config) ID [38], PID [15106], GUID [d17d3b87-1734-4f16-8773-4d429bbc9384], Zone [default], Active Roles [automate,database_operations,database_owner,ems_inventory,ems_operations,event,reporting,scheduler,smartstate,user_interface,web_services,websocket], Assigned Roles [automate,database_operations,database_owner,ems_inventory,ems_operations,event,reporting,scheduler,smartstate,user_interface,web_services,websocket], Configuration:
[----] I, [2019-02-25T09:51:13.754086 #15106:58af5c]  INFO -- :
---
:count: 2
:gc_interval: 900
:heartbeat_freq: 10
:heartbeat_timeout: 120
:memory_threshold: 1500000000
:nice_delta: 1
:parent_time_threshold: 180
:poll: 1
:poll_escalate_max: 30
:poll_method: :normal
:restart_interval: 0
:starting_timeout: 600
:stopping_timeout: 600
:cpu_usage_threshold: 100
:dequeue_method: :drb
:queue_timeout: 600
[----] I, [2019-02-25T09:51:13.754127 #15106:58af5c]  INFO -- : ---
[----] I, [2019-02-25T09:51:13.754316 #15106:58af5c]  INFO -- :
---
:guid: d17d3b87-1734-4f16-8773-4d429bbc9384
[----] I, [2019-02-25T09:51:13.754396 #15106:58af5c]  INFO -- : MIQ(MiqPriorityWorker::Runner#message_sync_config) MIQ(MiqPriorityWorker::Runner) Synchronizing configuration complete...

Comment 4 errata-xmlrpc 2019-03-06 09:50:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0453