Bug 2017978

Summary: [RHOSP18][Deployment][RFE] Switch to show/hide host_status field in server detail response to non-admins
Product: Red Hat OpenStack Reporter: Artom Lifshitz <alifshit>
Component: openstack-tripleo-heat-templatesAssignee: Bogdan Dobrelya <bdobreli>
Status: CLOSED DEFERRED QA Contact: Joe H. Rahme <jhakimra>
Severity: high Docs Contact:
Priority: low    
Version: 18.0 (Zed)CC: bdobreli, egallen, jkreger, mariel, mburns, mwitt
Target Milestone: AlphaKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-tripleo-heat-templates-17.0.1-0.20221201081418.e675ecb.el9osttrunk Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2024774 2150082 (view as bug list) Environment:
Last Closed: 2023-04-13 19:10:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version: Yoga
Embargoed:
Bug Depends On:    
Bug Blocks: 2150082    

Description Artom Lifshitz 2021-10-27 20:03:32 UTC
We would like to have a switch to show/hide the host_status field in the server details response to all users, not just admins. In certain clouds, knowing this information can help normal users understand why their apparently ACTIVE instance is unreachable. Mechanics-wise, this is similar to BZ 1982283, in that it's a tht configurable to tweak Nova policy.

Comment 4 Bogdan Dobrelya 2021-11-02 11:42:12 UTC
To unblock this, please decide on the scoping and needed backports of the dependency bz 1982283 for 16.x and 17?

mschuppert: if there is now a request for 17 or 16, we'd have to clone the BZ for those releases
mschuppert: but as it is a RFE also do an exception request (for 16.2)

Comment 5 Artom Lifshitz 2021-11-02 13:36:21 UTC
Julia can confirm, but targeting this at OSP 18 should be fine. The customer is expected to file a Support Exception to do this manually until OSP 18.

Comment 6 Julia Kreger 2021-11-08 13:46:57 UTC
I believe that is correct. During the call with the customer where this was discussed, it was explicitly stated that this would end up having to be OSP18 most likely.

Comment 7 melanie witt 2021-11-18 22:03:51 UTC
A recent rhbz email notification reminded me that I opened a rhbz for this a few months ago:

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

I'll close that ^ as a duplicate of this rhbz.

Comment 8 melanie witt 2021-11-18 22:05:38 UTC
*** Bug 1994072 has been marked as a duplicate of this bug. ***

Comment 13 Artom Lifshitz 2023-04-13 18:52:11 UTC
Similar to https://bugzilla.redhat.com/show_bug.cgi?id=1982283, moving to NEW in order to determine how we handle custom policy in a NextGen world.

Comment 14 Artom Lifshitz 2023-04-13 19:09:46 UTC
Now tracked in https://issues.redhat.com/browse/OSPRH-62