Description of problem: After an upgrade from 16.2 to 17.1, one can be in a so-called multi-rhel state: some compute nodes will be on osp17.1 but with the underlying os being 8.4 instead of 9.2. This is driven by specific role files. Enforcement during update ensure that for each version of OSP we have the corresponding expected OS version subscribed. For OSP17.1 this is rhel 9.2. Thus for the compute role still being on 8.4 we have an error as the OSP version (17.1) doesn't match the OS version (8.4 instead of 9.2). To prevent the error we have the role parameter name "rhsm_enforce" which can be set to false, thus preventing the check from being applied and the error from happening. A slight improvement, depending on how long this multi-rhel state would last could be to be able to specify the expected os version for some role. A prototype of the code change required is attached to this bz, basically we would have a new role parameter that would enable one to override the expected version of the os.
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 (Release of components for Red Hat OpenStack Platform 17.1.1 (Wallaby)), 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/RHBA-2023:5138