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.