summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* [stable-only] Drop lower-constraints jobstein-eolElod Illes2022-04-223-185/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | During the PTG the TC discussed the topic and decided to drop the job completely. Since the latest job configuration broke all stable gate for nova (older than yoga) this is needed there to unblock our gates. For dropping the job on master let's wait to the resolution as the gate is not broken there, hence the patch is stable-only. Conflicts: lower-constraints.txt tox.ini NOTE(elod.illes): conflict is due to branch specific settings (lower constraints changes, tox target did not define usedevelop). Besides, there is no need for pinning requirements-check job to ubuntu-bionic locally in .zuul.yaml, as it is pinned already in requirements repository's stable/stein. Change-Id: I514f6b337ffefef90a0ce9ab0b4afd083caa277e (cherry picked from commit 15b72717f2f3bd79791b913f1b294a19ced47ca7) (cherry picked from commit ba3c5b81abce49fb86981bdcc0013068b54d4f61) (cherry picked from commit 327693af402e4dd0c03fe247c4cee7beaedd2852) (cherry picked from commit 8ff36f184dd7aedf9adfdbdf8845504557e2bef5) (cherry picked from commit e0b030a1d2b7c63157fd2c621c1830f0867c53f8) (cherry picked from commit 156ce0b2477240d88ea42a1e4b6b6f951adbfd10)
* [stable-only] Pin virtualenv and setuptoolsBalazs Gibizer2021-10-111-1/+5
| | | | | | | | | | | | | | | | | | | | Setuptools 58.0 (bundled in virtualenv 20.8) breaks the installation of decorator 3.4.0. So this patch pins virtualenv to avoid the break. As the used 'require' feature was introduced in tox in version 3.2 [1], the required minversion has to be bumped, too. [1] https://tox.readthedocs.io/en/latest/config.html#conf-requires Conflicts: tox.ini NOTE(elod.illes): The conflict is because change I331c42a1a79b8a79d9afd04edb136c8c31dc483c is not in Stein. Change-Id: I26b2a14e0b91c0ab77299c3e4fbed5f7916fe8cf (cherry picked from commit b27f8e9adfcf2db3c83722c42e055ba5065ad06e) (cherry picked from commit f1be212a86262f128e73f7201b7b3e51334f1ab4)
* Merge "Avoid lazy-loading instance.flavor in cold migration" into stable/steinstable/steinZuul2021-08-283-2/+11
|\
| * Avoid lazy-loading instance.flavor in cold migrationTakashi NATSUME2021-02-103-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The instance.flavor is lazy-loaded currently in the resize method in nova/compute/api.py. Set expected_attrs=['flavor'] at the common.get_instance in the _migrate method in nova/api/openstack/compute/migrate_server.py to avid lazy-loading instance.flavor. Change-Id: Iba3b7c3e027ec78395a102c1fed46fa7a2ffa7be Closes-Bug: #1829877 (cherry picked from commit 8f78dc68d99182079ba44f2725ad27ff0078afb1)
* | Merge "Prevent archiving of pci_devices records because of 'instance_uuid'" ↵Zuul2021-08-252-2/+21
|\ \ | | | | | | | | | into stable/stein
| * | Prevent archiving of pci_devices records because of 'instance_uuid'melanie witt2020-11-022-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently in the archive_deleted_rows code, we will attempt to clean up "residue" of deleted instance records by assuming any table with a 'instance_uuid' column represents data tied to an instance's lifecycle and delete such records. This behavior poses a problem in the case where an instance has a PCI device allocated and someone deletes the instance. The 'instance_uuid' column in the pci_devices table is used to track the allocation association of a PCI with an instance. There is a small time window during which the instance record has been deleted but the PCI device has not yet been freed from a database record perspective as PCI devices are freed during the _complete_deletion method in the compute manager as part of the resource tracker update call. Records in the pci_devices table are anyway not related to the lifecycle of instances so they should not be considered residue to clean up if an instance is deleted. This adds a condition to avoid archiving pci_devices on the basis of an instance association. Closes-Bug: #1899541 Conflicts: nova/db/sqlalchemy/api.py nova/tests/functional/db/test_archive.py NOTE(melwitt): The conflicts are because change I9725f752f8aef8066f7c9705e87610cad887bf8e (refactor nova-manage archive_deleted_rows) and change Id16c3d91d9ce5db9ffd125b59fffbfedf4a6843d (nova-manage db archive_deleted_rows is not multi-cell aware) are not in Stein. Change-Id: Ie62d3566230aa3e2786d129adbb2e3570b06e4c6 (cherry picked from commit 1c256cf774693e2395ae8fe4a7a2f416a7aeb03a) (cherry picked from commit 09784db62fcd01124a101c4c69cab6e71e1ac781) (cherry picked from commit 79df36fecf8c8be5ae9d59397882ac844852043e) (cherry picked from commit e3bb6119cf2d0a503768979312aea4d10cf85cda)
* | | Move 'check-cherry-picks' test to gate, n-v checkStephen Finucane2021-08-162-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This currently runs in the 'check' pipeline, as part of the pep8 job, which causes otherwise perfectly valid backports to report as failing CI. There's no reason a stable core shouldn't be encouraged to review these patches: we simply want to prevent them *merging* before their parent(s). Resolve this conflict by moving the check to separate voting job in the 'gate' pipeline as well as a non-voting job in the 'check' pipeline to catch more obvious issues. Conflicts: .zuul.yaml NOTE(elod.illes): conflict is due to train related zuul job updates, like Ia1289f038b92c36dbdd79bcdf12d7cb95a3e5aa9 that is not present in stein. Change-Id: Id3e4452883f6a3cf44ff58b39ded82e882e28c23 Signed-off-by: Stephen Finucane <stephenfin@redhat.com> (cherry picked from commit 98b01c9a59df4912f5a162c2c52d1f00c84d24c2) (cherry picked from commit fef0305abefbf165fecb883f03bce97f525a790a) (cherry picked from commit b7677ae08ae151858ecb0e67039e54bb3df89700) (cherry picked from commit 91314f7fbba312d4438fa446804f692d316512a8) (cherry picked from commit de94f429474713a68d5efc53677bc468f02dc112)
* | | Merge "[neutron] Get only ID and name of the SGs from Neutron" into stable/steinZuul2021-07-171-1/+7
|\ \ \
| * | | [neutron] Get only ID and name of the SGs from NeutronSlawek Kaplonski2021-07-091-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the VM booting process Nova asks Neutron for the security groups of the project. If there are no any fields specified, Neutron will prepare list of security groups with all fields, including rules. In case if project got many SGs, it may take long time as rules needs to be loaded separately for each SG on Neutron's side. During booting of the VM, Nova really needs only "id" and "name" of the security groups so this patch limits request to only those 2 fields. This lazy loading of the SG rules was introduced in Neutron in [1] and [2]. [1] https://review.opendev.org/#/c/630401/ [2] https://review.opendev.org/#/c/637407/ Related-Bug: #1865223 Change-Id: I15c3119857970c38541f4de270bd561166334548 (cherry picked from commit 388498ac5fa15ed8deef06ec061ea47e4a1b7377) (cherry picked from commit 4f49545afaf3cd453796d48ba96b9a82d11c01bf) (cherry picked from commit f7d84db5876b30d6849877799c08ebc65ac077ca) (cherry picked from commit be4a514c8aea073a9188cfc878c9afcc9b03cb28) (cherry picked from commit 1aa571103f90228ddf3dc27386486196ad58ba0e)
* | | | Error anti-affinity violation on migrationsRodrigo Barbieri2021-07-093-27/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Error-out the migrations (cold and live) whenever the anti-affinity policy is violated. This addresses violations when multiple concurrent migrations are requested. Added detection on: - prep_resize - check_can_live_migration_destination - pre_live_migration The improved method of detection now locks based on group_id and considers other migrations in-progress as well. Conflicts: nova/tests/unit/compute/test_compute_mgr.py NOTE: Conflicts are because the following changes are not in Stein: * Ia00277ac8a68a635db85f9e0ce2c6d8df396e0d8 (Set migrate_data.vifs only when using multiple port bindings) * I3c917796cb30d11e7db1e235ac1625d2a743aaa2 (NUMA live migration support) * I2f3434f06489d8b6cb80933bcb1ea1e841049ba5 (Support migrating SRIOV port with bandwidth) * I292a0e2d840bbf657ba6d0932f9a3decbcb2778f ([FUP] Follow-up patch for SR-IOV live migration) * I734cc01dce13f9e75a16639faf890ddb1661b7eb (SR-IOV Live migration indirect port support) Summary of conflicts: Cherry-picked pulled many non-related newer unit tests. Cleaned those up and adjusted: - Removed 2 extra params of check_can_live_migrate_destination invocations. - Adjusted request_spec variable of unit test test_prep_resize_errors_migration. - Removed extra tab spacing on a unit test. Closes-bug: #1821755 Change-Id: I32e6214568bb57f7613ddeba2c2c46da0320fabc (cherry picked from commit 33c8af1f8c46c9c37fcc28fb3409fbd3a78ae39f) (cherry picked from commit 8b62a4ec9bf617dfb2da046c25a9f76b33516508) (cherry picked from commit 6ede6df7f41db809de19e124d3d4994180598f19) (cherry picked from commit bf90a1e06181f6b328b967124e538c6e2579b2e5) (cherry picked from commit a22d1b04de9e6ebc33b5ab9871b86f8e4022e7a9)
* | | | Merge "Validate id as integer for os-aggregates" into stable/steinZuul2021-06-202-21/+85
|\ \ \ \
| * | | | Validate id as integer for os-aggregatesJohannes Kulik2020-11-272-21/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the api-ref, the id passed to calls in os-aggregates is supposed to be an integer. No function validated this, so any value passed to these functions would directly reach the DB. While this is fine for SQLite, making a query with a string for an integer column on other databases like PostgreSQL results in a DBError exception and thus a HTTP 500 instead of 400 or 404. This commit adds validation for the id parameter the same way it's already done for other endpoints. Change-Id: I83817f7301680801beaee375825f02eda526eda1 Closes-Bug: 1865040 (cherry picked from commit 2e70a1717f25652912886cbefa3f40e6df908c00) (cherry picked from commit 4653245ddcf989ebac4b964a41d881d78cf9ae2c)
* | | | | Merge "Improve error log when snapshot fails" into stable/steinZuul2021-06-173-0/+12
|\ \ \ \ \ | |_|/ / / |/| | | |
| * | | | Improve error log when snapshot failsVu Tran2021-03-253-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If snapshot creation via glance fails due to lack of space or over quota, we want to have a clearer error message. Change-Id: Ic9133f6bc14d4fe766d37a438bf52c33e89da768 Closes-Bug: #1613770 (cherry picked from commit 024bf10d8aec5e58111793a9652b16682eb61b7c) (cherry picked from commit 9e9c022bde3a3ffdf0dd87e21bf9afde0dbc1e74)
* | | | | Merge "Add config parameter 'live_migration_scheme' to live migration with ↵Zuul2021-04-131-1/+10
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | tls guide" into stable/stein
| * | | | | Add config parameter 'live_migration_scheme' to live migration with tls guideJosephine Seifert2021-03-261-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the config option 'live_migration_scheme = tls' to the secure live migration guide. To let the live migration use the qemu native tls, some configuration of the compute nodes is needed. The guide describes this but misses the 'live_migration_scheme' config option. It is necessary to set 'live_migration_scheme' to tls to use the connection uri for encrypted traffic. Without this parameter everything seems to work, but the unencrypted tcp-connection is still used for the live migration. Closes-Bug: #1919357 Change-Id: Ia5130d411706bf7e1c983156158011a3bc6d5cd6 (cherry picked from commit 5d5ff82bab1dfb12e6223446b1cf20db6a348f38) (cherry picked from commit 276b8db5afd945bfc56ccfadd25bcce1b6df9cb7) (cherry picked from commit a968289b1f89b52d7396b66294f768c732583849) (cherry picked from commit 8559ceeec4e52651a272d08ef344d7c03520ed19)
* | | | | | Correctly disable greendnsArtom Lifshitz2021-04-031-10/+13
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we were setting the environment variable to disable greendns in eventlet *after* import eventlet. This has no effect, as eventlet processes environment variables at import time. This patch moves the setting of EVENTLET_NO_GREENDNS before importing eventlet in order to correctly disable greendns. Closes-bug: 1895322 Change-Id: I4deed815c8984df095019a7f61d089f233f1fc66 (cherry picked from commit 7c1d964faab33a02fe2366b5194611252be045fc) (cherry picked from commit 79e6b7fd30a04cdb2374abcaf496b6b5b76084ff) (cherry picked from commit 4984b3b75b5f7086b7464d9acb940e3fb0334a5e)
* | | | | Use subqueryload() instead of joinedload() for (system_)metadatamelanie witt2021-03-172-1/+24
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, when we "get" a single instance from the database and we load metadata and system_metadata, we do so using a joinedload() which does JOINs with the respective tables. Because of the one-to-many relationship between an instance and (system_)metadata records, doing the database query this way can result in a large number of additional rows being returned unnecessarily and cause a large data transfer. This is similar to the problem addressed by change I0610fb16ccce2ee95c318589c8abcc30613a3fe9 which added separate queries for (system_)metadata when we "get" multiple instances. We don't, however, reuse the same code for this change because _instances_fill_metadata converts the instance database object to a dict, and some callers of _instance_get_by_uuid need to be able to access an instance database object attached to the session (example: instance_update_and_get_original). By using subqueryload() [1], we can perform the additional queries for (system_)metadata to solve the problem with a similar approach. Closes-Bug: #1799298 [1] https://docs.sqlalchemy.org/en/13/orm/loading_relationships.html#subquery-eager-loading Change-Id: I5c071f70f669966e9807b38e99077c1cae5b4606 (cherry picked from commit e728fe668a6de886455f2dbaf655c8a151462c8c) (cherry picked from commit 63d2e62c3a223f883ca810f4c66a2a236cf3d483) (cherry picked from commit e7a45e0335e4cf44fec7f7b8d2505f5b95445cf9) (cherry picked from commit 4350074029ffbc03ab238c442ec86fab6560e365)
* | | | Merge "[stable-only] Specify IPv6 CIDR in tempest-slow-py3" into stable/steinZuul2021-03-171-0/+16
|\ \ \ \
| * | | | [stable-only] Specify IPv6 CIDR in tempest-slow-py3melanie witt2021-03-161-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a copy of a neutron patch [1] which specifies the CIDR used by the public network in the tempest-slow-py3 job. The original bug [2] was fixed in tempest [3] but since devstack pins TEMPEST_BRANCH=26.0.0 for stable/stein, we must do a one-off fix in-tree to fix our job. Related-Bug: #1914037 [1] https://review.opendev.org/c/openstack/neutron/+/777389 [2] https://bugs.launchpad.net/neutron/+bug/1914037 [3] https://review.opendev.org/c/openstack/tempest/+/774764 Change-Id: I8b559084ac424a868a3a3b387fc51bf056dbd3df
* | | | | [stable-only] gate: Pin CEPH_RELEASE to nautilus in LM hookLee Yarwood2021-03-122-0/+6
| |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I1edd5a50079f325fa143a7e0d51b3aa3bb5ed45d moved the branchless devstack-plugin-ceph project to the Octopus release of Ceph that drops support for py2. As this was still the default on stable/train this breaks the nova-live-migration and nova-grenade jobs. This change works around this by pinning the CEPH_RELEASE to nautilus within the LM hook as was previously used prior to the above landing. Note that the devstack-plugin-ceph-tempest job from the plugin repo continues to pass as it is correctly pinned to the Luminous release that supports py2. If anything the above enforces the need to move away from these hook scripts and instead inherit our base ceph jobs from this repo in the future to avoid the Ceph release jumping around like this. Change-Id: I1d029ebe78b16ed2d4345201b515baf3701533d5 (cherry picked from commit ff570d1b4e9b9777405ae75cc09eae2ce255bf19)
* | | | Update pci stat pools based on PCI device changesHemanth Nakkina2021-01-216-33/+220
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At start up of nova-compute service, the PCI stat pools are populated based on information in pci_devices table in Nova database. The pools are updated only when new device is added or removed but not on any device changes like device type. If an existing device is configured as SRIOV and nova-compute is restarted, the pci_devices table gets updated but the device is still listed under the old pool in pci_tracker.stats.pool (in-memory object). This patch looks for device type updates in existing devices and updates the pools accordingly. Conflicts: nova/tests/functional/libvirt/test_pci_sriov_servers.py To avoid the conflicts and make the new functional test execute, following changes are performed in the new test case - Passing hostname as argument to self._get_connection() is not supported in stable/stein and hence dropped the argument. - Compute nodes cannot be retreived by host and nodename should also be included in stable/stein. So modified the function call to use objects.ComputeNode.get_by_host_and_nodename instead. Change-Id: Id4ebb06e634a612c8be4be6c678d8265e0b99730 Closes-Bug: #1892361 (cherry picked from commit b8695de6da56db42b83b9d9d4c330148766644be) (cherry picked from commit d8b8a8193b6b8228f6e7d6bde68b5ea6bb53dd8b) (cherry picked from commit f58399cf496566e39d11f82a61e0b47900f2eafa) (cherry picked from commit 8378785f995dd4bec2a5a20f7bf5946b3075120d)
* | | Merge "Change default num_retries for glance to 3" into stable/steinZuul2021-01-164-8/+19
|\ \ \
| * | | Change default num_retries for glance to 3Keigo Noha2021-01-144-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the default value of num_retries for glance is 0. It means that the request to glance is sent only one time. On the other hand, neutron and cinder clients set the default value to 3. To align the default value for retry to other components, we should change the default value to 3. Closes-Bug: #1888168 Change-Id: Ibbd4bd26408328b9e1a1128b3794721405631193 (cherry picked from commit 662af9fab6eacb46bcaee38d076d33c2c0f82b9b) (cherry picked from commit 1f9dd694b937cc55a81a64fdce442829f009afb3) (cherry picked from commit ca2fd8098a47cf2c38351dc4c8c65c7c5fe0afc3)
* | | | [stable-only] Fix lower-constraints jobLee Yarwood2021-01-085-25/+12
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the newly encountered issues with the lower-constraints job (came up with the new pip version with the new dependency resolver) and sets back the job as voting job. install_command was not yet removed from tox.ini in stable/stein and seemingly it is used in lower-constraints job, thus the job fails with contradicting constraints over package 'coverage'. As a minimal fix the install_command is added to the lower-constraints tox target, too. warlock==1.3.0 is set as lower-constraint, but during the installation a requirement to warlock!=1.3.0 causes failure of the lower-constraints job. * pyroute2 version bumped to match os-vif's constraint * psycopg2 and oslo.messaging bumped to make lower-constraints job pass * zVMCloudConnector supports python 3.6 only from vesion 1.2.2 * cryptography version needed to be bumped as it conflicts with another dependency and causes the new pip resolver to time out at gate Change-Id: Iae3fcac484f060e8dbeef299d594b8ade8ab3b70
* | | [stable-only] Cap bandit and make lower-constraints job non-votingLee Yarwood2021-01-083-2/+17
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | The 1.6.3 [1] release has dropped support for py2 [2] so cap to 1.6.2 when using py2. sphinx requirements needed to be changed in doc/requirements.txt to make requirements-check job pass. [1] https://github.com/PyCQA/bandit/releases/tag/1.6.3 [2] https://github.com/PyCQA/bandit/pull/615 Closes-Bug: #1907438 Change-Id: Ie5221bf37c6ed9268a4aa0737ffcdd811e39360a
* | Merge "Sanity check instance mapping during scheduling" into stable/steinZuul2020-11-162-17/+120
|\ \
| * | Sanity check instance mapping during schedulingMatt Riedemann2020-10-062-17/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mnaser reported a weird case where an instance was found in both cell0 (deleted there) and in cell1 (not deleted there but in error state from a failed build). It's unclear how this could happen besides some weird clustered rabbitmq issue where maybe the schedule and build request to conductor happens twice for the same instance and one picks a host and tries to build and the other fails during scheduling and is buried in cell0. To avoid a split brain situation like this, we add a sanity check in _bury_in_cell0 to make sure the instance mapping is not pointing at a cell when we go to update it to cell0. Similarly a check is added in the schedule_and_build_instances flow (the code is moved to a private method to make it easier to test). Worst case is this is unnecessary but doesn't hurt anything, best case is this helps avoid split brain clustered rabbit issues. Closes-Bug: #1775934 Change-Id: I335113f0ec59516cb337d34b6fc9078ea202130f (cherry picked from commit 5b552518e1abdc63fb33c633661e30e4b2fe775e) (cherry picked from commit efc35b1c5293c7c6c85f8cf9fd9d8cd8de71d1d5)
* | | Follow up for cherry-pick check for merge patchstein-em19.3.2melanie witt2020-10-301-1/+1
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a follow up to change I8e4e5afc773d53dee9c1c24951bb07a45ddc2f1a which fixed an issue with validation when the topmost patch after a Zuul rebase is a merge patch. We need to also use the $commit_hash variable for the check for stable-only patches, else it will incorrectly fail because it is checking the merge patch's commit message. Change-Id: Ia725346b65dd5e2f16aa049c74b45d99e22b3524 (cherry picked from commit 1e10461c71cb78226824988b8c903448ba7a8a76) (cherry picked from commit f1e4f6b078baf72e83cd7341c380aa0fc511519e) (cherry picked from commit e676a480544b3fa71fcaa984a658e2131b7538c5) (cherry picked from commit 115b43ed3e9514d9e4fb41da5582f0b185ecd10a)
* | Merge "Allow tap interface with multiqueue" into stable/steinZuul2020-10-273-18/+111
|\ \
| * | Allow tap interface with multiqueueRodrigo Barbieri2020-10-133-18/+111
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When vif_type="tap" (such as when using calico), attempting to create an instance using an image that has the property hw_vif_multiqueue_enabled=True fails, because the interface is always being created without multiqueue flags. This change checks if the property is defined and passes the multiqueue parameter to create the tap interface accordingly. In case the multiqueue parameter is passed but the vif_model is not virtio (or unspecified), the old behavior is maintained. Conflicts: nova/virt/libvirt/vif.py NOTE: The conflict is for not having change Iab16a15a5f141a7f7aae4172b092c50ee7964597 in stable/stein. Change-Id: I0307c43dcd0cace1620d2ac75925651d4ee2e96c Closes-bug: #1893263 (cherry picked from commit 84cfc8e9ab1396ec17abcfc9646c7d40f1d966ae) (cherry picked from commit a69845f3732843ee1451b2e4ebf547d9801e898d) (cherry picked from commit 750655c19daf4e8d0dcf35d3b1cab5e6d8ac69ba)
* | Merge "libvirt:driver:Disallow AIO=native when 'O_DIRECT' is not available" ↵Zuul2020-10-233-0/+75
|\ \ | | | | | | | | | into stable/stein
| * | libvirt:driver:Disallow AIO=native when 'O_DIRECT' is not availableArthur Dayne2020-09-113-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because of the libvirt issue[1], there is a bug[2] that if we set cache mode whose write semantic is not O_DIRECT (.i.e unsafe, writeback or writethrough), there will be a problem with the volume drivers (.i.e nova.virt.libvirt.volume.LibvirtISCSIVolumeDriver, nova.virt.libvirt.volume.LibvirtNFSVolumeDriver and so on), which designate native io explicitly. That problem will generate a libvirt xml for the instance, whose content contains ``` ... <disk ... > <driver ... cache='unsafe/writeback/writethrough' io='native' /> </disk> ... ``` In turn, it will fail to start the instance or attach the disk. > When qemu is configured with a block device that has aio=native set, but > the cache mode doesn't use O_DIRECT (i.e. isn't cache=none/directsync or any > unnamed mode with explicit cache.direct=on), then the raw-posix block driver > for local files and block devices will silently fall back to aio=threads. > The blockdev-add interface rejects such combinations, but qemu can't > change the existing legacy interfaces that libvirt uses today. [1]: https://github.com/libvirt/libvirt/commit/058384003db776c580d0e5a3016a6384e8eb7b92 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1086704 Closes-Bug: #1841363 Change-Id: If9acc054100a6733f3659a15dd9fc2d462e84d64 (cherry picked from commit af2405e1181d70cdf60bcd0e40b3e80f2db2e3a6) (cherry picked from commit 0bd58921a1fcaffcc4fac25f63434c9cab93b061) (cherry picked from commit d92fe4f3e69db51b7bbad52a1fe1740e37bade9a)
* | | Merge "Set different VirtualDevice.key" into stable/steinZuul2020-10-152-4/+94
|\ \ \ | |_|/ |/| |
| * | Set different VirtualDevice.keyyingjisun2020-10-062-4/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In vSphere 7.0, the VirtualDevice.key cannot be the same any more. So set different values to VirtualDevice.key Change-Id: I574ed88729d2f0760ea4065cc0e542eea8d20cc2 Closes-Bug: #1892961 (cherry picked from commit a5d153a4c64f6947531823c0df91be5cbc491977) (cherry picked from commit 0ea5bcca9d7bebf835b173c5e75dc89e666bcb99) (cherry picked from commit 75c0327a67bf12f4b18d6bb1561fc34bb7081264)
* | | Merge "post live migration: don't call Neutron needlessly" into stable/steinZuul2020-10-063-5/+18
|\ \ \ | |/ / |/| |
| * | post live migration: don't call Neutron needlesslyArtom Lifshitz2020-09-093-5/+18
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In bug 1879787, the call to network_api.get_instance_nw_info() in _post_live_migration() on the source compute manager eventually calls out to the Neutron REST API. If this fails, the exception is unhandled, and the migrating instance - which is fully running on the destination at this point - will never be updated in the database. This update normally happens later in post_live_migration_at_destination(). The network_info variable obtained from get_instance_nw_info() is used for two things: notifications - which aren't critical - and unplugging the instance's vifs on the source - which is very important! It turns out that at the time of the get_instance_nw_info() call, the network info in the instance info cache is still valid for unplugging the source vifs. The port bindings on the destination are only activated by the network_api.migrate_instance_start() [1] call that happens shortly *after* the problematic get_instance_nw_info() call. In other words, get_instance_nw_info() will always return the source ports. Because of that, we can replace it with a call to instance.get_network_info(). [1] https://opendev.org/openstack/nova/src/commit/d9e04c4ff0b1a9c3383f1848dc846e93030d83cb/nova/network/neutronv2/api.py#L2493-L2522 Change-Id: If0fbae33ce2af198188c91638afef939256c2556 Closes-bug: 1879787 (cherry picked from commit 6488a5dfb293831a448596e2084f484dd0bfa916) (cherry picked from commit 2c949cb3eea9cd9282060da12d32771582953aa2) (cherry picked from commit 7ace26e4bcd69a0a3d780cfae9f6745e4177b6c2)
* | Merge "Add checks for volume status when rebuilding" into stable/steinZuul2020-09-174-4/+94
|\ \
| * | Add checks for volume status when rebuildingsunhao2020-09-084-4/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rebuilding, we should only allow detaching the volume with 'in-use' status, volume in status such as 'retyping' should not allowed. Change-Id: I7f93cfd18f948134c9cb429dea55740d2cf97994 Closes-Bug: #1489304 (cherry picked from commit 10e9a9b9fc62a3cf72c3717e3621ed95d3cf5519) (cherry picked from commit bcbeae2c605f4ab4ad805dddccac802928a180b6) (cherry picked from commit 683005df39cbb825ff0702cd91773ad16d7b3998)
* | | Merge "Removed the host FQDN from the exception message" into stable/steinZuul2020-09-113-3/+3
|\ \ \ | |_|/ |/| |
| * | Removed the host FQDN from the exception messagePraharshitha Metla2020-09-033-3/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deletion of an instance after disabling the hypervisor by a non-admin user leaks the host fqdn in fault msg of instance.Removing the 'host' field from the error message of HypervisorUnavaiable cause it's leaking host fqdn to non-admin users. The admin user will see the Hypervisor unavailable exception msg but will be able to figure on which compute host the guest is on and that the connection is broken. Change-Id: I0eae19399670f59c17c9a1a24e1bfcbf1b514e7b Closes-Bug: #1851587 (cherry picked from commit a89ffab83261060bbb9dedb2b8de6297b2d07efd) (cherry picked from commit ff82601204e9d724b3032dc94c49fa5c8de2699b) (cherry picked from commit c5abbd17b5552209e53ad61713c4787f47f463c6)
* | Merge "compute: Don't delete the original attachment during pre LM rollback" ↵19.3.1Zuul2020-09-043-8/+24
|\ \ | | | | | | | | | into stable/stein
| * | compute: Don't delete the original attachment during pre LM rollbackLee Yarwood2020-09-033-8/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I0bfb11296430dfffe9b091ae7c3a793617bd9d0d introduced support for live migration with cinderv3 volume attachments during Queens. This initial support handled failures in pre_live_migration directly by removing any attachments created on the destination and reverting to the original attachment ids before re-raising the caught exception to the source compute. It also added rollback code within the main _rollback_live_migration method but missed that this would also be called during a pre_live_migration rollback. As a result after a failure in pre_live_migration _rollback_live_migration will attempt to delete the source host volume attachments referenced by the bdm before updating the bdms with the now non-existent attachment ids, leaving the volumes in an `available` state in Cinder as they have no attachment records associated with them anymore. This change aims to resolve this within _rollback_volume_bdms by ensuring that the current and original attachment_ids are not equal before requesting that the current attachment referenced by the bdm is deleted. When called after a failure in pre_live_migration this should result in no attempt being made to remove the original source host attachments from Cinder. Note that the following changes muddy the waters slightly here but introduced no actual changes to the logic within _rollback_live_migration: * I0f3ab6604d8b79bdb75cf67571e359cfecc039d8 reworked some of the error handling in Rocky but isn't the source of the issue here. * Ibe9215c07a1ee00e0e121c69bcf7ee1b1b80fae0 reworked _rollback_live_migration to use the provided source_bdms. * I6bc73e8c8f98d9955f33f309beb8a7c56981b553 then refactored _rollback_live_migration, moving the logic into a self contained _rollback_volume_bdms method. Closes-Bug: #1889108 Change-Id: I9edb36c4df1cc0d8b529e669f06540de71766085 (cherry picked from commit 2102f1834a6ac9fd870bfb457b28a2172f33e281) (cherry picked from commit 034b2fa8fea0e34fed95a2ba728e4387ce4e78de) (cherry picked from commit c6c3483a41c2a53bcfafdfe3475283b0379f7f1d)
* | | Merge "Add regression tests for bug #1889108" into stable/steinZuul2020-09-041-0/+114
|\ \ \ | |/ /
| * | Add regression tests for bug #1889108Lee Yarwood2020-09-031-0/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NOTE(lyarwood): The only required changes in stable/stein is the switch the original CinderFixtureNewAttachFlow fixture. Related-Bug: #1889108 Change-Id: Ib9dbc792dc918e7ea45915e2c1dbd96be82ef562 (cherry picked from commit 4c970f499c31370495d84c91a10319d308d13fb9) (cherry picked from commit 6db72002a65f30ac44b8df0a642b400ea272247e) (cherry picked from commit 6a9bb79fc088f4f888373a6ab2c8a70f143aa20d)
* | | Merge "compute: refactor volume bdm rollback error handling" into stable/steinZuul2020-09-042-27/+178
|\ \ \ | |/ /
| * | compute: refactor volume bdm rollback error handlingLee Yarwood2020-09-032-27/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously any exception while rolling back the connection_info and attachment_id of volume bdms would result in the overall attempt to rollback a LM failing. This change refactors this specific bdm rollback logic into two self contained methods that ignore by default errors where possible to allow the LM rollback attempt to continue. Change-Id: I6bc73e8c8f98d9955f33f309beb8a7c56981b553 (cherry picked from commit 9524a5a1b5745f6064f88cbfbf5bbfae3a973bef) (cherry picked from commit 377dc5bda9369e50c0c4a893564fc218b4b31fb1)
* | | Merge "compute: Use source_bdms to reset attachment_ids during LM rollback" ↵Zuul2020-09-043-24/+34
|\ \ \ | |/ / | | | | | | into stable/stein
| * | compute: Use source_bdms to reset attachment_ids during LM rollbackLee Yarwood2020-08-273-24/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | As we now provide the original source bdms during rollback we can also use them to reset any volume attachment ids to the ids used by the source compute host. Change-Id: Ibe9215c07a1ee00e0e121c69bcf7ee1b1b80fae0 (cherry picked from commit 0eea5041c4047bf3ab8bf71973926d80592e5e5c)
* | | Merge "Robustify attachment tracking in CinderFixtureNewAttachFlow" into ↵Zuul2020-09-041-20/+37
|\ \ \ | |/ / | | | | | | stable/stein
View Lorry Controller Status