Cloned this as related to the "host_status show/hide" enablement. In OSC currently you can only see host_status in 'openstack server show' and we could add host_status to 'openstack server list --long' to make things potentially easier for users. The 'openstack server list --long' command already shows "Host" so I think "Host Status" fits in well alongside that.

+++ This bug was initially created as a clone of Bug #2017978 +++

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.

— Additional comment from RHEL Program Management on 2021-10-29 10:11:40 UTC —

The keyword FutureFeature has been added. If this bug is not a FutureFeature, please remove from the Summary field any strings containing "RFE, rfe, FutureFeature, FEAT, Feat, feat". Additionally, if this feature is being backported to a previous release, clone this BZ to older releases and add the "FeatureBackport" keyword only to those cloned BZs.

— Additional comment from Bogdan Dobrelya on 2021-10-29 10:13:21 UTC —

Not sure about 16.1 scope for this RFE, but we could surely backport that down to upstream Train since that should be a minor config change

— Additional comment from Bogdan Dobrelya on 2021-11-02 11:18:58 UTC —

Nope, we cannot backport that to 16.x w/o https://bugzilla.redhat.com/show_bug.cgi?id=1982283 going first. Since the required puppet API policy fixes from bz 1982283 has yet backported for 16.x and probably won't be?

— Additional comment from Bogdan Dobrelya on 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)

— Additional comment from Artom Lifshitz on 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.

— Additional comment from Julia Kreger on 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.

— Additional comment from melanie witt on 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.

— Additional comment from melanie witt on 2021-11-18 22:05:38 UTC —