Bug 2233560

BTW, manually changing OS_COMPUTE_API_VERSION value in the overcloudrc file from 2.latest to 2.1 solves the issue, but that shouldn't be happening in the first place:

(overcloud) [stack@undercloud ~]$ openstack endpoint list | grep nova
| 555f388113394b278f2366699d09e1f3 | regionOne | nova         | compute        | True    | internal  | http://172.16.2.230:8774/v2.1                 |
| 767290a7278343e2ba010ff2f637a9bf | regionOne | nova         | compute        | True    | public    | http://10.0.0.230:8774/v2.1                   |
| 77d2f56911f646adbbc62d7fab1211b7 | regionOne | nova         | compute        | True    | admin     | http://172.16.2.230:8774/v2.1

(overcloud) [stack@undercloud ~]$ cat overcloudrc 
# Clear any old environment that may conflict.
for key in $( set | awk '{FS="="}  /^OS_/ {print $1}' ); do unset $key ; done
export OS_USERNAME=admin
export OS_PROJECT_NAME=admin
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_NO_CACHE=True
export OS_CLOUD=overcloud
export no_proxy=,10.0.0.230,192.0.2.18
export PYTHONWARNINGS='ignore:Certificate has no, ignore:A true SSLContext object is not available'
export OS_AUTH_TYPE=password
export OS_PASSWORD=zqCJanWlH2sMwT7VwWwaLJ4ay
export OS_AUTH_URL=http://10.0.0.230:5000
export OS_IDENTITY_API_VERSION=3
export OS_COMPUTE_API_VERSION=2.1                 <--- Changed here from 2.latest to 2.1
export OS_IMAGE_API_VERSION=2
export OS_VOLUME_API_VERSION=3
export OS_REGION_NAME=regionOne

# Add OS_CLOUD to PS1
if [ -z "${CLOUDPROMPT_ENABLED:-}" ]; then
    export PS1=${PS1:-""}
    export PS1=\${OS_CLOUD:+"(\$OS_CLOUD)"}\ $PS1
    export CLOUDPROMPT_ENABLED=1
fi

(overcloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+------+-----+------+-----------+-------+-----------+
| ID                                   | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+------+-----+------+-----------+-------+-----------+
| 4c1db5f3-fb29-4f6c-8ff1-914c6abebc99 | tiny | 512 |    1 |         0 |     1 | True      |
+--------------------------------------+------+-----+------+-----------+-------+-----------+

FYI,

I've submitted a patch in the upstream to fix it:

https://review.opendev.org/c/openstack/tripleo-common/+/892379

Waiting for review.

export OS_COMPUTE_API_VERSION=2.latest is not a real micorvsion and comptue does not recommend defaultign to latest in general.

(In reply to smooney from comment #3)
> export OS_COMPUTE_API_VERSION=2.latest is not a real micorvsion and comptue
> does not recommend defaultign to latest in general.

Exactly, but that was hardcoded in upstream, so I've submitted a patch to correct it, setting up '2.1' instead of the '2.latest:

https://review.opendev.org/c/openstack/tripleo-common/+/892548

Waiting for Zuul's checking.

PS. From what I could see in the repo logs, this was the justification for implementing that (but this is clearly creating a bug):

$ cat releasenotes/notes/export_os_nova_api_version-d5d1501306f8013b.yaml
---
fixes:
  - |
    openstack cli doesn't negotiate a microversion. Live migration and
    multiattach are 2 examples of operations which require arcane incantations
    to make them work correctly, and therefore usually don't.
    This adds ``OS_COMPUTE_API_VERSION=2.latest`` to the overcloudrc file to
    fix it.

$ git log | grep f3e3208fb784ec1d726b3a7252ec8825d64d7103 -A14

commit f3e3208fb784ec1d726b3a7252ec8825d64d7103
Author: Martin Schuppert <mschuppert>
Date:   Mon Oct 7 11:07:51 2019 +0200

    Add OS_COMPUTE_API_VERSION to overcloudrc
    
    openstack cli doesn't negotiate a microversion. Live migration and
    multiattach are 2 examples of operations which require arcane
    incantations
    to make them work correctly, and therefore usually don't.
    This adds ``OS_COMPUTE_API_VERSION=2.latest`` to the overcloudrc
    file to fix it.
    
    Change-Id: I6bb4ef5d3d0e53b12f8636b998d7f7c2426c2b60

With the patch proposed upstream and +1'ed by Compute (Sean specifically), I'd like to move this back to DF. I don't believe there's further action for Compute to take, since this is fairly minor and we will not be QE'ing this or writing docs for it.

I don't think this is really owned by DF.
DF does not own how individual services are deployed, and the problem is
the specific configuration for nova client.

DF can help reviewing the patch (and QEing it if David has remaining bw)
but the required change should be maintained by Compute again the piece
is tightly related to the compute commands in openstackclient.

Wil(In reply to Takashi Kajinami from comment #6)
> I don't think this is really owned by DF.
> DF does not own how individual services are deployed, and the problem is
> the specific configuration for nova client.
> 
> DF can help reviewing the patch (and QEing it if David has remaining bw)
> but the required change should be maintained by Compute again the piece
> is tightly related to the compute commands in openstackclient.

Will we it backport this to Wallaby in downstream too?

I don't understand why this is closed before the actual fix was merged.
Anyway I added +A to the patch so it would be imported to future RHOSP17.1 as long as it is merged later.

Note that this task is currently assigned to Compute team (I'm from DF) so in case you need further question
then please reach out to the person in Compute (like Artom or Sean).
We, DF, are not the main owner but are kind of secondary who help reviewing/merging the tripleo patches.

(In reply to Takashi Kajinami from comment #8)
> I don't understand why this is closed before the actual fix was merged.

Artom,

Could you reply to this one, please?

> Anyway I added +A to the patch so it would be imported to future RHOSP17.1
> as long as it is merged later.
> 

Cool.

> Note that this task is currently assigned to Compute team (I'm from DF) so
> in case you need further question
> then please reach out to the person in Compute (like Artom or Sean).
> We, DF, are not the main owner but are kind of secondary who help
> reviewing/merging the tripleo patches.

Takashi,

Thank you for help, reviewing and replying.

Also patched in downstream via cherry-pick:

https://code.engineering.redhat.com/gerrit/c/openstack-tripleo-common/+/446494

(In reply to Alexon Oliveira from comment #9)
> (In reply to Takashi Kajinami from comment #8)
> > I don't understand why this is closed before the actual fix was merged.
> 
> Artom,
> 
> Could you reply to this one, please?

As I've said previously, DFG:Compute will neither QE this, nor write docs for it (and this has nothing to do with which DFG owns the patch - the patch is just too minor). With the upstream patch merged (and expected to make it into downstream 17.1 in the near future via an import), our work is done, and I feel safe in closing this as UPSTREAM.

> 
> > Anyway I added +A to the patch so it would be imported to future RHOSP17.1
> > as long as it is merged later.
> > 
> 
> Cool.
> 
> > Note that this task is currently assigned to Compute team (I'm from DF) so
> > in case you need further question
> > then please reach out to the person in Compute (like Artom or Sean).
> > We, DF, are not the main owner but are kind of secondary who help
> > reviewing/merging the tripleo patches.
> 
> Takashi,
> 
> Thank you for help, reviewing and replying.

*** Bug 2252389 has been marked as a duplicate of this bug. ***

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 (Moderate: Red Hat OpenStack Platform 17.1 (openstack-tripleo-common) security update), 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/RHSA-2024:0216