Description of problem: Bug #1946956 is seeking to change the default x86_64 machine types defined by NovaHWMachineType for new deployments of OSP 17 to q35. During an upgrade from OSP 16.2 to OSP 17 however NovaHWMachineType should remain pinned to the pc-i440fx-rhel7.6.0 machine type for x86_64 instances as originally used in the deployment. This will allow the new logic introduced into nova by RFE bug #1581414 (and partially backported by bug #1944607 to 16.2) to register the existing machine types before operators can update NovaHWMachineType by following a workflow to be documented by bug #1946898.
There is an action item for DFG:UV/Upgrades please: We need a pre-upgrade validation to make sure that a machine type override is set to the value shipped as of https://review.opendev.org/785027 . And for the Docs DFG Artom will provide extra information
@alifshit Artom, would you please provide extra information for the documentation team items pending?
(In reply to Bogdan Dobrelya from comment #14) > @alifshit Artom, would you please provide extra information for > the documentation team items pending? I think Artom is referring to this: https://bugzilla.redhat.com/show_bug.cgi?id=1946898#c4 -- [OSP-17] Document deprecation of 'i440fx' machine type in OSP-17; and migration path to 'q35'
> @alifshit Artom, would you please provide extra information for the documentation team items pending? I'm not sure what information this is, as I don't see any specific questions in this BZ from Docs or anyone else. Since this has moved to 17.1 we still have runway left, but the tl;dr is: * Greenfield 17.x deployemnt: q35 machine type * FFU to 17.1: - *during* the FFU, keep whatever was already set, so either the pc default, or whatever custom value the customer had. I can't speak to the mechanics of *how* to achieve that, though. - *after* the FFU, we have tooling to record per-instance machine type, so that needs to run either manually or automatically. This is also being done in 16.2 at host init automatically for all instances on the host, but we need to make sure all instances have it recorded. - Once the per-instance machine type is recorded, change the default to q35, as RHEL 10 will lose pc support (as far as we currently know).
> - Once the per-instance machine type is recorded, change the default to q35, as RHEL 10 will lose pc support (as far as we currently know). what is the next step, to do something with the recorded machine types?
> - *during* the FFU, keep whatever was already set, so either the pc default, or whatever custom value the customer had. I can't speak to the mechanics of *how* to achieve that, though. I think there is a way to achieve that, after we have upgraded t-h-t package to match the OSP17.1 FFU target state. When running upgrade prepare, to hold back explicitly the last used machine type value from the most recent state of deployment - into the role/default parameters. Could DF and Upgrade folk to confirm that please? @lbezdick
At the moment we provide environments/nova-hw-machine-type-upgrade.yaml to upgrade prepare and we probably expect this environment to be used until all the RHEL8 machines are removed from the environment. This means we need reasonable doctext explaining use of this file and how to get rid of it. It also means this env file will not be automatically provided by upgrade as users have to use it pass the upgrade point.