Bug 2166680
| Summary: | [OSP17.1] JSON problem with attribute 'hypervisor_hostname' not accepted only in tempest | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Maor <mblue> |
| Component: | openstack-tempest | Assignee: | Lukas Piwowarski <lpiwowar> |
| Status: | CLOSED NOTABUG | QA Contact: | Martin Kopec <mkopec> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 17.1 (Wallaby) | CC: | apevec, ekuris, lhh, lpiwowar, ltoscano, rlandy, slinaber, udesale |
| Target Milestone: | --- | Keywords: | Automation, AutomationBlocker, Triaged |
| Target Release: | --- | Flags: | lpiwowar:
needinfo+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-04-20 13:11:05 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: | |
| Embargoed: | |||
|
Comment 2
Luigi Toscano
2023-02-03 09:21:23 UTC
This is probably not an issue of tempest not having schema for 2.75. Tempest uses the schemas only to verify responses and there is no expected "hypervisor_hostname" field in the response for the create server request [1]. It looks like the "Invalid input for field/attribute server. Value ..." error in [2] was raised on the nova side. The reason why it was raised is probably, as pointed out but Luigi, an incorrect or missing microversion value in the "X-OpenStack-Nova-API-Version" header. To ensure that the correct microversion is utilized min_microversion and max_microversion class variables can be used (for example like here [4]). Also, the reason why the request did not fail when it was created using the CLI [3] is the fact that the "X-OpenStack-Nova-API-Version" value was set to 2.88 by the CLI (search for "X-OpenStack-Nova-API-Version: 2.88") [1] https://docs.openstack.org/api-ref/compute/?expanded=create-server-detail#id12 [2] http://pastebin.test.redhat.com/1090395 [3] http://pastebin.test.redhat.com/1090389 [4] https://opendev.org/openstack/tempest/src/commit/1569290be06e61d63061ae35a997aff0ebad68f1/tempest/api/compute/servers/test_servers.py#L163 Hi Maor, based on the above comment it seems there is something wrong with the test, do I understand correctly that we're talking about a new test for neutron-tempest-plugin? Do you have a link for the review? We could take a look and discuss there. Thank you for the code. I see that the parent BaseTempestTestCase class in neutron-tempest-plugin does not support min_microversion and max_microversion parameters [1]. If you want to use these parameters you have to modify the parent class similarly like here [2] or here [3]. You can ping me if you need help with that. Here's [4] a good resource that explains how microversion testing in tempest works and how to implement tests that need to specify microversion. [1] https://opendev.org/openstack/neutron-tempest-plugin/src/commit/a8d67e6f3bccf9cd9946b0dcd73eb95c248783e1/neutron_tempest_plugin/scenario/base.py#L90 [2] https://opendev.org/openstack/ironic-tempest-plugin/src/branch/master/ironic_tempest_plugin/tests/api/base.py#L60 [3] https://opendev.org/openstack/tempest/src/commit/94649e792e08fcfb3859a4f7cf314070287f985c/tempest/api/compute/base.py#L36 [4] https://docs.openstack.org/tempest/latest/microversion_testing.html#how-to-implement-microversion-tests As per our conversation with Maor we can close this bug. To sum up, this is not a tempest bug. To use hypervisor_hostname field correct min_microversion and max_microversion parameters need to be specified by the test. Tempest provides methods to specify these options but there need to be some changes on the neutron-tempest-plugin's side if it wants to be able to specify the microversions in its tests (see previous comment). Also, what led to the conclusion that this can be closed is the fact that the issue was resolved without the need to use the hypervisor_hostname field. |