Bug 1596142 - When setting roles through an API call, the company name and zone are set back to default values.
Summary: When setting roles through an API call, the company name and zone are set bac...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: API
Version: 5.9.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: 5.10.z
Assignee: Jason Frey
QA Contact: Parthvi Vala
URL:
Whiteboard:
: 1597382 (view as bug list)
Depends On:
Blocks: 1595269
TreeView+ depends on / blocked
 
Reported: 2018-06-28 10:05 UTC by Imaan
Modified: 2021-09-09 14:47 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-30 19:12:34 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Current logs, both with debug on and off, when bug occurs (979.95 KB, application/x-xz)
2018-07-10 13:34 UTC, Dustin Scott
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github ManageIQ integration_tests pull 9604 0 'None' closed [1LP][RFR] Manual test cleanup and qe-test-coverage test cases 2020-05-19 13:47:43 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.