What is the probability and severity of the issue? I.e. the overall risk

A. The reboot hypervisors before adoption requirement is permanent for OSP17.x hosts updated to OSP17.1.4.

This issue requires a blocker as we want to remove that requirement for greenfield OSP17.1.4 deployments that use a pre-provisioned servers.

The severity is not high for the start, but it may raise over time, as the numbers of greenfield OSP17.1.4 environments will grow over time as well.

Does this affect specific configurations, hardware, environmental factors, etc.?

A. Any greenfield OSP17.1.4 that use a pre-provisioned servers, going to have that reboot hypervisors before adoption requirement.

Are any partners relying on this functionality in order to ship an ecosystem product?

A. N/A

What proportion of our customers could hit this issue?

A. No data. Depends on the proportions of environments for RHOSO adoption being: a) upgraded from 16.x, b) minor-updated for OSP17.4, c) a greenfield OSP17.4, d) using pre-provisioned servers ; and also depends on the distribution of these categories over the time

Does this happen for only a specific use case?

A. The reboot requirement is "unwelcome" for adoption to RHOSO only

What proportion of our CI infrastructure, automation, and test cases does this issue impact?

A. There is a simple w/a for that in CI/test envs, which is to install systemd-container BEFORE any VMs/tests started.

Is this a regression in supported functionality from a previous release?

A. It is not a regression, it became a problem for adopting OSP17 into RHOSO18

Is there a clear workaround?

A. Complete the reboot hypervisors before adoption requirement (involves live migrating VMs from hypervisors and rebooting them, one by one).

Is there potential doc impact?

A. Yes, we need to document the reboot hypervisors before adoption requirement , and explain for which cases it may be omitted.

If this is a UI issue:

A. No

Is the UI still fit for its purpose/goal?

A. No

Does the bug compromise the overall trustworthiness of the UI?

A. No

Overall context and effort – is the overall impact bigger/worse than the bug in isolation? For example, 1 workaround might seem ok, 5 is getting ugly, 20 might be unacceptable (rough numbers).

A. 5, and may grow over time, as the adoption of greenfield osp17.4 expands