Description of problem: In an early design the Container Definition table was supposed to be used for Replication Controllers information as well. For that reason it is decoupled from the Container table. It is worth investigating if we can simplify the Container and Container Definition models (1-to-1) by consolidating the data into a single table.
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 it to Low/Low.
Done by Ari. PRs involved (perhaps incomplete): https://github.com/ManageIQ/manageiq-schema/pull/24 https://github.com/ManageIQ/manageiq/pull/15393 https://github.com/ManageIQ/manageiq-providers-kubernetes/pull/42 https://github.com/ManageIQ/manageiq-providers-kubernetes/pull/76 https://github.com/ManageIQ/manageiq-providers-openshift/pull/40 https://github.com/ManageIQ/manageiq-ui-classic/pull/1760 https://github.com/ManageIQ/manageiq-automation_engine/pull/55 https://github.com/ManageIQ/manageiq/pull/15721 QE: this was just a refactoring, no new functionality. Old functionality this could have broken if buggy, would be nice to verify: After refresh UI shows partial info for pod containers that have spec but no status, and full info for running containers. I *think* a simple way to get pod stuck without containerStatuses is specify non-existing image. Another is request > quota so the pod is not scheduled.
CFME Version: 5.9.0.11.20171127204214_e316988 Verification: Verified via regression testing of Inventory Refresh
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/RHSA-2018:0380