FTR: the new deployment default is already set to the q35 alias [0], here we want to move that to the "versioned type"

[0] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/785027/8/deployment/nova/nova-compute-container-puppet.yaml

Can you provide the latest status for this high severity, high priority BZ?

To my understanding it depends on bz 1946961. The latest status is https://bugzilla.redhat.com/show_bug.cgi?id=1946961#c13

@Artrom, would you please help to address that?
Moving this back to NEW.

we had planned to do the pinning in ooo  as part of upgrades but that was rejected if i understand correctly

https://review.opendev.org/c/openstack/tripleo-heat-templates/+/785027/ mand the unversioned q35 alias the default.

https://review.opendev.org/c/openstack/tripleo-heat-templates/+/828894/ then attempted to pinn the version on upgrade.

https://bugzilla.redhat.com/show_bug.cgi?id=1946961 was tracking the effort to pin this automatically  that is now going to be converted to a docs issue.
so the upgrade procedure will explain how to pin the machine type via the templates.

this bz was tracking pinning the machine type to a versioned machine type downstream only for 17.
so  we should just create  a downstream only patch to do that.

bogdan can you find the oldest rhel 9 bases q35 machine type and propose a patch to set that as our downstream default in ooo.

Kashyap had a thread on this topic on rhos-compute where we agreed on the machine type previously
"Let's work out the machine types OSP needs in RHEL9 for incoming migration"

Kashyap do you know what version machine type should be used explicitly.

Can we close this as a dup for https://bugzilla.redhat.com/show_bug.cgi?id=1946961 then?

no it's not a duplicate.
for greenfield deployments, we need to pin to "pc-q35-rhel9.0.0"

for upgrades since we are not doing it automatically, we need to document how to pin to osp 16 machine type and then later change to the new machine type.


so this is tracking the former pinning the machine type downstream only to pc-q35-rhel9.0.0

and  https://bugzilla.redhat.com/show_bug.cgi?id=1946961 is the documentation task and upgrade procedure testing for 16.2 to 17.1

Thank you for explaining, Sean. @kchamart, please confirm if I should pin it in downstream only for osp17 to pc-q35-rhel9.0.0

(In reply to Bogdan Dobrelya from comment #12)
> Thank you for explaining, Sean. @kchamart, please confirm if I
> should pin it in downstream only for osp17 to pc-q35-rhel9.0.0

Hi, Bodgan (and Sean):

Yes, for OSP 17.0, plese pin it to "pc-q35-rhel9.0.0".

Just for additional info:  

- RHEL9 also supports "pc-i440fx-rhel7.6.0" machine type — the default
  machine type in OSP 16.1 and 16.2.  This is to allow incoming live
  migrations from OSP 16.1 and 16.2 to OSP 17 (RHEL9).

    
- These are the machine types supported on RHEL-9.0: [QEMU version:
  qemu-kvm-core-6.2.0-4.el9.x86_64]

    $ /usr/libexec/qemu-kvm -M help
    Supported machines are:
    pc                   RHEL 7.6.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.6.0)
    pc-i440fx-rhel7.6.0  RHEL 7.6.0 PC (i440FX + PIIX, 1996) (default)
    q35                  RHEL-9.0.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel9.0.0)
    pc-q35-rhel9.0.0     RHEL-9.0.0 PC (Q35 + ICH9, 2009)
    pc-q35-rhel8.6.0     RHEL-8.6.0 PC (Q35 + ICH9, 2009)
    pc-q35-rhel8.5.0     RHEL-8.5.0 PC (Q35 + ICH9, 2009)
    pc-q35-rhel8.4.0     RHEL-8.4.0 PC (Q35 + ICH9, 2009)
    pc-q35-rhel8.3.0     RHEL-8.3.0 PC (Q35 + ICH9, 2009)
    pc-q35-rhel8.2.0     RHEL-8.2.0 PC (Q35 + ICH9, 2009)
    pc-q35-rhel8.1.0     RHEL-8.1.0 PC (Q35 + ICH9, 2009)
    pc-q35-rhel8.0.0     RHEL-8.0.0 PC (Q35 + ICH9, 2009)
    pc-q35-rhel7.6.0     RHEL-7.6.0 PC (Q35 + ICH9, 2009)
    none                 empty machine

- This is the doc bug on moving from 'pc' to 'q35':

    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'

@kashyap.cv @pgrist Any update on this? I see it has been proposed as a blocker but is still On Dev

TRAC team have marked this as GA blocker but not a Beta blocker

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.0 (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/RHEA-2022:6543