Bug 1946961

Summary: [OSP 17] Pin NovaHWMachineType to OSP 16.2 values during upgrade
Product: Red Hat OpenStack Reporter: Lee Yarwood <lyarwood>
Component: documentationAssignee: kgilliga
Status: CLOSED CURRENTRELEASE QA Contact: RHOS Documentation Team <rhos-docs>
Severity: high Docs Contact:
Priority: high    
Version: 17.0 (Wallaby)CC: alifshit, bdobreli, jgrosso, jpretori, kchamart, kgilliga, lbezdick, mburns, sgolovat, smooney
Target Milestone: betaKeywords: Patch, Triaged, UpgradeBlocker
Target Release: 17.1   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-06-13 20:13:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version: Wallaby
Embargoed:
Bug Depends On:    
Bug Blocks: 1946898, 1946978, 2016660    

Description Lee Yarwood 2021-04-07 11:21:41 UTC
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.

Comment 13 Bogdan Dobrelya 2022-03-21 16:43:50 UTC
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

Comment 14 Bogdan Dobrelya 2022-05-11 15:05:09 UTC
@alifshit Artom, would you please provide extra information for the documentation team items pending?

Comment 17 Kashyap Chamarthy 2022-06-29 05:33:00 UTC
(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'

Comment 18 Artom Lifshitz 2022-08-05 18:18:42 UTC
> @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).

Comment 20 Bogdan Dobrelya 2022-09-20 11:57:41 UTC
> - 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?

Comment 21 Bogdan Dobrelya 2022-09-20 12:02:37 UTC
>   - *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

Comment 26 Lukas Bezdicka 2023-04-18 08:49:17 UTC
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.