Bug 1596142

Summary: When setting roles through an API call, the company name and zone are set back to default values.
Product: Red Hat CloudForms Management Engine Reporter: Imaan <ikaur>
Component: APIAssignee: Jason Frey <jfrey>
Status: CLOSED NOTABUG QA Contact: Parthvi Vala <pvala>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.9.0CC: bsorota, cpelland, dscott, ikaur, jfrey, jocarter, mkourim, mshriver, obarenbo
Target Milestone: GA   
Target Release: 5.10.z   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-30 19:12:34 UTC Type: Bug
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:    
Bug Blocks: 1595269    
Attachments:
Description Flags
Current logs, both with debug on and off, when bug occurs none

Description Imaan 2018-06-28 10:05:18 UTC 
Description of problem:

When setting roles through an API call, the company name and zone are set back to default values.

Version-Release number of selected component (if applicable):

Red Hat CloudForms 4.6

How reproducible: 100%

API Query: Update/change the role using API.

Actual results: After the API call, the company name and zone are set back to default values.

Expected Results: The company name and zone should not change.
Comment 4 Dave Johnson 2018-06-28 10:42:40 UTC 
Please assess the impact of this issue and update the severity accordingly.  Please refer to https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity for a reminder on each severity's definition.

If it's something like a tracker bug where it doesn't matter, please set the severity to Low.
Comment 5 Chris Pelland 2018-07-03 13:38:18 UTC 
*** Bug 1597382 has been marked as a duplicate of this bug. ***
Comment 6 Jason Frey 2018-07-09 23:48:49 UTC 
Dustin,

Do you have logs for this issue?  I cannot duplicate it locally, but I think there is a race where multiple API workers are in play.  The way it works is that when either the API or UI worker gets a Settings change, it immediately updates it's in-memory cache, and then broadcast's a cache-invalidation to all other workers.  It's possible that the second call comes into the second worker before it has received the cache-invalidation broadcast.  So, under the covers it thinks the value was changed back.  I want to verify this before fixing it, so if you have logs, it will be very clear if I see alternating threads getting the changes.
Comment 7 Dustin Scott 2018-07-10 13:34:23 UTC 
Created attachment 1457824 [details]
Current logs, both with debug on and off, when bug occurs

Ran through the below routine twice.  First time with debug off, second with debug on:


curl -X PATCH -u 'admin:smartvm' -d "{\"server\":{\"name\":\"cfme-test-api\"}}" 'https://192.168.50.184/api/servers/1000000000001/settings' -k  | python -m json.tool
curl -X PATCH -u 'admin:smartvm' -d "{\"server\":{\"company\":\"api company\"}}" 'https://192.168.50.184/api/servers/1000000000001/settings' -k  | python -m json.tool
Comment 8 Dustin Scott 2018-07-10 13:35:19 UTC 
Jason, supplied needed info above.  See attached logs for details.
Comment 9 Dustin Scott 2018-07-10 13:38:56 UTC 
It should also be noted, that this system has had the settings changes applied for several days.  However, when I applied the new settings via the API, it reverted the server name completely back to EVM.  Other settings, such as SMTP and NTP settings, were also reverted as well.
Comment 11 Mike Shriver 2019-10-30 17:07:54 UTC 
Changing to NOTABUG as bug was not identified and fixed before BZ was closed. resetting qe_test_coverage as well, as QE can automate coverage of such behavior.