summaryrefslogtreecommitdiff
path: root/releasenotes/notes
Commit message (Collapse)AuthorAgeFilesLines
* Use force=True for os-brick disconnect during deletemelanie witt2023-05-101-0/+11
| | | | | | | | | | | | | | | | | | | | | | The 'force' parameter of os-brick's disconnect_volume() method allows callers to ignore flushing errors and ensure that devices are being removed from the host. We should use force=True when we are going to delete an instance to avoid leaving leftover devices connected to the compute host which could then potentially be reused to map to volumes to an instance that should not have access to those volumes. We can use force=True even when disconnecting a volume that will not be deleted on termination because os-brick will always attempt to flush and disconnect gracefully before forcefully removing devices. Closes-Bug: #2004555 Change-Id: I3629b84d3255a8fe9d8a7cea8c6131d7c40899e8 (cherry picked from commit db455548a12beac1153ce04eca5e728d7b773901) (cherry picked from commit efb01985db88d6333897018174649b425feaa1b4) (cherry picked from commit 8b4b99149a35663fc11d7d163082747b1b210b4d)
* Merge "Fix rescue volume-based instance" into stable/yoga25.1.1Zuul2023-04-201-0/+6
|\
| * Fix rescue volume-based instanceRajesh Tailor2023-01-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As of now, when attempting to rescue a volume-based instance using an image without the hw_rescue_device and/or hw_rescue_bus properties set, the rescue api call fails (as non-stable rescue for volume-based instances are not supported) leaving the instance in error state. This change checks for hw_rescue_device/hw_rescue_bus image properties before attempting to rescue and if the property is not set, then fail with proper error message, without changing instance state. Related-Bug: #1978958 Closes-Bug: #1926601 Change-Id: Id4c8c5f3b32985ac7d3d7c833b82e0876f7367c1 (cherry picked from commit 6eed55bf55469f4ceaa7d4d4eb1be635e14bc73b) (cherry picked from commit d00a848a735f98b028f5930798ee69ef205c8e2e)
* | ignore deleted server groups in validationSean Mooney2023-02-131-0/+13
|/ | | | | | | | | | This change simply catches the exception raised when we lookup a servergroup via a hint and the validation upcall is enabled. Change-Id: I858b4da35382a9f4dcf88f4b6db340e1f34eb82d Closes-Bug: #1890244 (cherry picked from commit cd2c2f359bbd4913cfe73199847bc35b2664aaa9)
* Add a workaround to skip hypervisor version check on LMKashyap Chamarthy2023-01-271-0/+13
| | | | | | | | | | | | | | | | | When turned on, this will disable the version-checking of hypervisors during live-migration. This can be useful for operators in certain scenarios when upgrading. E.g. if you want to relocate all instances off a compute node due to an emergency hardware issue, and you only have another old compute node ready at the time. Note, though: libvirt will do its own internal compatibility checks, and might still reject live migration if the destination is incompatible. Closes-Bug: #1982853 Change-Id: Iec387dcbc49ddb91ebf5cfd188224eaf6021c0e1 Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> (cherry picked from commit 00ed8a232bc22f48011e95a0b47750520a5b4d47)
* Gracefully ERROR in _init_instance if vnic_type changedBalazs Gibizer2023-01-111-0/+9
| | | | | | | | | | | | | | | | | | If the vnic_type of a bound port changes from "direct" to "macvtap" and then the compute service is restarted then during _init_instance nova tries to plug the vif of the changed port. However as it now has macvtap vnic_type nova tries to look up the netdev of the parent VF. Still that VF is consumed by the instance so there is no such netdev on the host OS. This error killed the compute service at startup due to unhandled exception. This patch adds the exception handler, logs an ERROR and continue initializing other instances on the host. Also this patch adds a detailed ERROR log when nova detects that the vnic_type changed during _heal_instance_info_cache periodic. Closes-Bug: #1981813 Change-Id: I1719f8eda04e8d15a3b01f0612977164c4e55e85 (cherry picked from commit e43bf900dc8ca66578603bed333c56b215b1876e)
* Merge "Handle "no RAM info was set" migration case" into stable/yogaZuul2022-12-201-0/+11
|\
| * Handle "no RAM info was set" migration caseBrett Milford2022-10-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This handles the case where the live migration monitoring thread may race and call jobStats() after the migration has completed resulting in the following error: libvirt.libvirtError: internal error: migration was active, but no RAM info was set Closes-Bug: #1982284 Change-Id: I77fdfa9cffbd44b2889f49f266b2582bcc6a4267 (cherry picked from commit 9fea934c71d3c2fa7fdd80c67d94e18466c5cf9a) (cherry picked from commit 00396fa9396324780c09161ed57a86b7e458c26f)
* | Merge "Retry attachment delete API call for 504 Gateway Timeout" into ↵Zuul2022-12-031-0/+7
|\ \ | | | | | | | | | stable/yoga
| * | Retry attachment delete API call for 504 Gateway TimeoutTakashi Kajinami2022-07-091-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When cinder-api runs behind a load balancer(eg haproxy), the load balancer can return 504 Gateway Timeout when cinder-api does not respond within timeout. This change ensures nova retries deleting a volume attachment in that case. Also this change makes nova ignore 404 in the API call. This is required because cinder might continue deleting the attachment even if the load balancer returns 504. This also helps us in the situation where the volume attachment was accidentally removed by users. Closes-Bug: #1978444 Change-Id: I593011d9f4c43cdae7a3d53b556c6e2a2b939989 (cherry picked from commit 8f4b740ca5292556f8e953a30f2a11ed4fbc2945)
* | | enable blocked VDPA move operationsSean Mooney2022-11-171-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change adds functional test for operations on servers with VDPA devices that are expected to work but currently blocked due to lack of testing or qemu bugs. cold-migrate, resize, evacuate,and shelve are enabled and tested by this patch Conflicts: nova/tests/functional/libvirt/test_pci_sriov_servers.py Closes-Bug: #1970467 Change-Id: I6e220cf3231670d156632e075fcf7701df744773 (cherry picked from commit 95f96ed3aa201bc5b90e589b288fa4039bc9c0d2)
* | | Record SRIOV PF MAC in the binding profileBalazs Gibizer2022-11-171-0/+9
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today Nova updates the mac_address of a direct-physical port to reflect the MAC address of the physical device the port is bound to. But this can only be done before the port is bound. However during migration Nova does not update the MAC when the port is bound to a different physical device on the destination host. This patch extends the libvirt virt driver to provide the MAC address of the PF in the pci_info returned to the resource tracker. This information will be then persisted in the extra_info field of the PciDevice object. Then the port update logic during migration, resize, live migration, evacuation and unshelve is also extended to record the MAC of physical device in the port binding profile according to the device on the destination host. The related neutron change Ib0638f5db69cb92daf6932890cb89e83cf84f295 uses this info from the binding profile to update the mac_address field of the port when the binding is activated. Closes-Bug: #1942329 Conflicts: nova/objects/pci_device.py nova/virt/libvirt/host.py Change-Id: Iad5e70b43a65c076134e1874cb8e75d1ba214fde (cherry picked from commit cd03bbc1c33e33872594cf002f0e7011ab8ea047)
* | For evacuation, ignore if task_state is not NoneAmit Uniyal2022-08-051-0/+11
| | | | | | | | | | | | | | | | ignore instance task state and continue with vm evacutaion Closes-Bug: #1978983 Change-Id: I5540df6c7497956219c06cff6f15b51c2c8bc29d (cherry picked from commit db919aa15f24c0d74f3c5c0e8341fad3f2392e57)
* | Merge "libvirt: Add a workaround to skip compareCPU() on destination" into ↵Zuul2022-08-011-0/+24
|\ \ | |/ |/| | | stable/yoga
| * libvirt: Add a workaround to skip compareCPU() on destinationKashyap Chamarthy2022-06-081-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nova's use of libvirt's compareCPU() API served its purpose over the years, but its design limitations break live migration in subtle ways. For example, the compareCPU() API compares against the host physical CPUID. Some of the features from this CPUID aren not exposed by KVM, and then there are some features that KVM emulates that are not in the host CPUID. The latter can cause bogus live migration failures. With QEMU >=2.9 and libvirt >= 4.4.0, libvirt will do the right thing in terms of CPU compatibility checks on the destination host during live migration. Nova satisfies these minimum version requirements by a good margin. So, provide a workaround to skip the CPU comparison check on the destination host before migrating a guest, and let libvirt handle it correctly. This workaround will be removed once Nova replaces the older libvirt APIs with their newer and improved counterparts[1][2]. - - - Note that Nova's libvirt driver calls compareCPU() in another method, _check_cpu_compatibility(); I did not remove its usage yet. As it needs more careful combing of the code, and then: - where possible, remove the usage of compareCPU() altogether, and rely on libvirt doing the right thing under the hood; or - where Nova _must_ do the CPU comparison checks, switch to the better libvirt CPU APIs -- baselineHypervisorCPU() and compareHypervisorCPU() -- that are described here[1]. This is work in progress[2]. [1] https://opendev.org/openstack/nova-specs/commit/70811da221035044e27 [2] https://review.opendev.org/q/topic:bp%252Fcpu-selection-with-hypervisor-consideration Change-Id: I444991584118a969e9ea04d352821b07ec0ba88d Closes-Bug: #1913716 Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Signed-off-by: Balazs Gibizer <bgibizer@redhat.com> (cherry picked from commit 267a40663cd8d0b94bbc5ebda4ece55a45753b64)
* | Merge "Fix segment-aware scheduling permissions error" into stable/yogaZuul2022-06-141-0/+7
|\ \ | |/ |/|
| * Fix segment-aware scheduling permissions errorAndrew Bonney2022-05-061-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Resolves a bug encountered when setting the Nova scheduler to be aware of Neutron routed provider network segments, by using 'query_placement_for_routed_network_aggregates'. Non-admin users attempting to access the 'segment_id' attribute of a subnet caused a traceback, resulting in instance creation failure. This patch ensures the Neutron client is initialised with an administrative context no matter what the requesting user's permissions are. Change-Id: Ic0f25e4d2395560fc2b68f3b469e266ac59abaa2 Closes-Bug: #1970383 (cherry picked from commit ee32934f34afd8e6df467361e9d71788cd36f6ee)
* | Fix pre_live_migration rollbackErlon R. Cruz2022-04-201-0/+10
|/ | | | | | | | | | | | | | | | | | | | During the pre live migration process, Nova performs most of the tasks related to the creation and operation of the VM in the destination host. That is done without interrupting any of the hardware in the source host. If the pre_live_migration fails, those same operations should be rolled back. Currently nova is sharing the _rollback_live_migration for both live and pre_live migration rollbacks, and that is causing the source host to try to re-attach network interfaces on the source host where they weren't actually de-attached. This patch fixes that by adding a conditional to allow nova to do different paths for migration and pre_live_migration rollbacks. Closes-bug: #1944619 Change-Id: I784190ac356695dd508e0ad8ec31d8eaa3ebee56 (cherry picked from commit 63ffba7496182f6f6f49a380f3c639fc3ded9772)
* Merge "Add the Yoga prelude section"25.0.0.0rc125.0.0Zuul2022-03-101-0/+49
|\
| * Add the Yoga prelude sectionSylvain Bauza2022-03-091-0/+49
| | | | | | | | | | | | Coming straight from the cycle highlights. Change-Id: I329092a352d44a6833efd11f5e9c5a1c6fc8d1be
* | Merge "reenable greendns in nova."Zuul2022-03-091-0/+14
|\ \ | |/ |/|
| * reenable greendns in nova.Sean Mooney2022-03-081-0/+14
| | | | | | | | | | | | | | | | | | | | | | Back in the days of centos 6 and python 2.6 eventlet greendns monkeypatching broke ipv6. As a result nova has run without greendns monkey patching ever since. This removes that old workaround allowing modern eventlet to use greendns for non blocking dns lookups. Closes-Bug: #1964149 Change-Id: Ia511879d2f5f50a3f63d180258abccf046a7264e
* | Merge "Lightos driver release note"Zuul2022-03-011-0/+8
|\ \
| * | Lightos driver release noteyuval brave2022-02-281-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | followup for: Change-Id Ic314b26695d9681d31a18adcec0794c2ff41fe71 - add release note - small nit in lighots unittests to remove the config option. Signed-off-by: Yuval Brave <yuval@lightbitslabs.com> Change-Id: Iace742c96580e97eff3a0dc1074f0722a5254217
* | | Merge "Complete phase-1 of RBAC community-wide goal"Zuul2022-02-271-0/+30
|\ \ \
| * | | Complete phase-1 of RBAC community-wide goalGhanshyam Mann2022-02-241-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After moving the nova APIs policy as per the new guidlines where system scoped token will be only allowed to access system level APIs and will not be allowed any operation on project level APIs. With that we do not need below base rules (who have hardcoded 'system_scope:all' check_str): - system_admin_api - system_reader_api - system_admin_or_owner - system_or_project_reader At this stage (phase-1 target), we allow below roles as targeted in phase-1 [1] 1. ADMIN(this is System Administrator with scope_type 'system' when scope enabled otherwise legacy admin) 2. PROJECT_ADMIN 3. PROJECT_MEMBER 4. PROJECT_READER & below one specific to nova 5. PROJECT_READER_OR_ADMIN (to allow system admin and project reader to list flavor extra specs) This complete the phase-1 of RBAC community-wide goal[2] for nova. Add release notes too. [1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#how-operator [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#yoga-timeline-7th-mar-2022 Partial implement blueprint policy-defaults-refresh-2 Change-Id: I075005d13ff6bfe048bbb21d80d71bf1602e4c02
* | | | Merge "Add reno for unified limits"Zuul2022-02-271-0/+43
|\ \ \ \
| * | | | Add reno for unified limitsJohn Garbutt2022-02-241-0/+43
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This first version should be considered as a preview, that will become more useable once more of the transition tooling has been implemented. Given the massive change, it seems prudent to get as much of this into operators hands as quickly as possible, so we can get some early feedback. blueprint unified-limits-nova Change-Id: I80ccca500d1a2eb8f19b5843a0d0d337c583e104
* | | | Merge "neutron: Remove references to dead 'qos-queue' extension"Zuul2022-02-271-0/+7
|\ \ \ \ | |_|_|/ |/| | |
| * | | neutron: Remove references to dead 'qos-queue' extensionStephen Finucane2021-09-021-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had assumed that this was used by the out-of-tree XenAPI driver, but it turns out to have been used by the VMWare NSX QoS extension [1]. This extension itself is now EOL and the code was removed from the vmware-nsx package over two years ago [2][3]. There are no remaining references to this former extension: $ cd vmware-nsx $ ag qos-queue $ git log -S qos-queue --oneline | head -1 26135f34a retire the NSX MH plugin We can safely remove this. A release note is included even though this is a vendor-specific feature that should really never have been merged. [1] https://github.com/openstack/neutron/blob/fe61e29f/doc/source/admin/archives/adv-features.rst#vmware-nsx-qos-extension [2] https://opendev.org/x/vmware-nsx/src/commit/b5f59ece9130016f8949ac1b6c7a242d0048795f/vmware_nsx/extensions/qos_queue.py [3] https://opendev.org/x/vmware-nsx/commit/26135f34acca66ce994e0dd4280e2e968ed10ce3 Change-Id: I90171131d671d1b9ef2f93cc13174ebb00e96033 Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
* | | | driver/secheduler/docs for Adds Pick guest CPU architecture based onJonathan Race2022-02-241-0/+10
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | host arch in libvirt driver support This is split 2 of 3 for the architecture emulation feature. This implements emulated multi-architecture support through qemu within OpenStack Nova. Additional config variable check to pull host architecture into hw_architecture field for emulation checks to be made. Adds a custom function that simply performs a check for hw_emulation_architecture field being set, allowing for core code to function as normal while enabling a simple check to enable emulated architectures to follow the same path as all multi-arch support already established for physical nodes but instead levaraging qemu which allows for the overall emulation. Added check for domain xml unit test to strip arch from the os tag, as it is not required uefi checks, and only leveraged for emulation checks. Added additional test cases test_driver validating emulation functionality with checking hw_emulation_architecture against the os_arch/hw_architecture field. Added required os-traits and settings for scheduler request_filter. Added RISCV64 to architecture enum for better support in driver. Implements: blueprint pick-guest-arch-based-on-host-arch-in-libvirt-driver Closes-Bug: 1863728 Change-Id: Ia070a29186c6123cf51e1b17373c2dc69676ae7c Signed-off-by: Jonathan Race <jrace@augusta.edu>
* | | Merge "manage: Add image_property commands"Zuul2022-02-241-0/+17
|\ \ \
| * | | manage: Add image_property commandsLee Yarwood2022-02-241-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds an image property show and image property set command to nova-manage to allow users to update image properties stored for an instance in system metadata without having to rebuild the instance. This is intended to ease migration to new machine types, as updating the machine type could potentially invalidate the existing image properties of an instance. Co-Authored-By: melanie witt <melwittt@gmail.com> Blueprint: libvirt-device-bus-model-update Change-Id: Ic8783053778cf4614742186e94059d5675121db1
* | | | Merge "libvirt: Register defaults for undefined hw image properties"Zuul2022-02-241-0/+15
|\ \ \ \ | |/ / /
| * | | libvirt: Register defaults for undefined hw image propertiesLee Yarwood2022-02-231-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, device bus and model types defined as image properties associated with an instance are always used when launching instances with the libvirt driver. When these types are not defined as image properties, their values either come from libosinfo or those directly hardcoded into the libvirt driver. This means that any changes to the defaults provided by libosinfo or the libvirt driver could result in unforeseen changes to existing instances. This has been encountered in the past as libosinfo assumes that libvirt domain definitions are static when OpenStack Nova specifically rewrites and redefines these domains during a hard reboot or migration allowing changes to possibly occur. This adds persistence of device bus and model type defaults to the instance's system metadata so that they will remain stable across reboots and migrations. Co-Authored-By: melanie witt <melwittt@gmail.com> Blueprint: libvirt-device-bus-model-update Change-Id: I44d41a134a7fab638e2ea88e7ae86d25070e8a43
* | | | Merge "VMware: Support volumes backed by VStorageObject"Zuul2022-02-231-0/+5
|\ \ \ \
| * | | | VMware: Support volumes backed by VStorageObjectalecorps2022-02-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vSphere 6.5 introduced APIs to manage virtual disks (volumes) as first class objects. The new managed disk entity is called VStorageObject aka First Class Disk (FCD). Adding support for volumes backed by VStorageObject. Change-Id: I4a5a9d3537dc175508f0a0fd82507c498737d1a5
* | | | | Merge "Support use_multipath for NVME driver"Zuul2022-02-221-0/+7
|\ \ \ \ \
| * | | | | Support use_multipath for NVME driverLior Friedman2022-02-101-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Initiate connector for LibvirtNVMEVolumeDriver driver with use_multipath argument. Change-Id: I20f6aa2d422259601c44d024099cd5760a8e21c6
* | | | | | Merge "[nova/libvirt] Support for checking and enabling SMM when needed"Zuul2022-02-171-0/+7
|\ \ \ \ \ \
| * | | | | | [nova/libvirt] Support for checking and enabling SMM when neededImran Hussain2022-02-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check the features list we get from the firmware descriptor file to see if we need SMM (requires-smm), if so then enable it as we aren't using the libvirt built in mechanism to enable it when grabbing the right firmware. Closes-Bug: 1958636 Change-Id: I890b3021a29fa546d9e36b21b1111e8537cd0020 Signed-off-by: Imran Hussain <ih@imranh.co.uk>
* | | | | | | Merge "neutron: Allow to spawn VMs with port without IP address"Zuul2022-02-171-0/+3
|\ \ \ \ \ \ \
| * | | | | | | neutron: Allow to spawn VMs with port without IP addressRodolfo Alonso Hernandez2022-02-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, all ports attached to an instance must have a fixed IP address already associated with them ('immediate' IP allocation policy) or must get one during instance creation ('deferred' IP allocation policy). However, there are situations where is can be helpful to create a port without an IP address, for example, when there is an IP address but it is not managed by neutron (this is unfortunately quite common for certain NFV applications). The 'vm-without-l3-address' neutron blueprint [1] added support for these kinds of ports, but until now, nova still insisted on either a pre-existing IP assignment or deferred IP assignment. Close the gap and allow nova to use these ports. Thanks to I438cbab43b45b5f7afc820b77fcf5a0e823d0eff we no longer need to check after binding to ensure we're on a backend that has 'connectivity' of 'l2'. [1] https://specs.openstack.org/openstack/neutron-specs/specs/newton/unaddressed-port.html Change-Id: I3c49f151ff1391e0a72c073d0d9c24e986c08938 Implements-blueprint: vm-boot-with-unaddressed-port
* | | | | | | | Merge "Fix to implement 'pack' or 'spread' VM's NUMA cells"Zuul2022-02-171-0/+10
|\ \ \ \ \ \ \ \ | |_|_|_|_|/ / / |/| | | | | | |
| * | | | | | | Fix to implement 'pack' or 'spread' VM's NUMA cellsIlya Popov2022-02-081-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cells mean NUMA cells below in text. By default, first instance's cell are placed to the host's cell with id 0, so it will be exhausted first. Than host's cell with id 1 will be used and exhausted. It will lead to error placing instance with number of cells in NUMA topology equal to host's cells number if some instances with one cell topology are placed on cell with id 0 before. Fix will perform several sorts to put less used cells at the beginning of host_cells list based on PCI devices, memory and cpu usage when packing_host_numa_cells_allocation_strategy is set to False (so called 'spread strategy'), or will try to place all VM's cell to the same host's cell untill it will be completely exhausted and only after will start to use next available host's cell (so called 'pack strategy'), when the configuration option packing_host_numa_cells_allocation_strategy is set to True. Partial-Bug: #1940668 Change-Id: I03c4db3c36a780aac19841b750ff59acd3572ec6
* | | | | | | | Merge "Gracefull recovery when attaching volume fails"Zuul2022-02-141-0/+8
|\ \ \ \ \ \ \ \ | |_|_|_|/ / / / |/| | | | | | |
| * | | | | | | Gracefull recovery when attaching volume failsFelix Huettner2022-02-091-0/+8
| |/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to attach a volume to an already running instance the nova-api requests the nova-compute service to create a BlockDeviceMapping. If the nova-api does not receive a response within `rpc_response_timeout` it will treat the request as failed and raise an exception. There are multiple cases where nova-compute actually already processed the request and just the reply did not reach the nova-api in time (see bug report). After the failed request the database will contain a BlockDeviceMapping entry for the volume + instance combination that will never be cleaned up again. This entry also causes the nova-api to reject all future attachments of this volume to this instance (as it assumes it is already attached). To work around this we check if a BlockDeviceMapping has already been created when we see a messaging timeout. If this is the case we can safely delete it as the compute node has already finished processing and we will no longer pick it up. This allows users to try the request again. A previous fix was abandoned but without a clear reason ([1]). [1]: https://review.opendev.org/c/openstack/nova/+/731804 Closes-Bug: 1960401 Change-Id: I17f4d7d2cb129c4ec1479cc4e5d723da75d3a527
* | | | | | | Merge "[yoga] Add support for VNIC_REMOTE_MANAGED"Zuul2022-02-091-0/+27
|\ \ \ \ \ \ \
| * | | | | | | [yoga] Add support for VNIC_REMOTE_MANAGEDDmitrii Shcherbakov2022-02-091-0/+27
| |/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow instances to be created with VNIC_TYPE_REMOTE_MANAGED ports. Those ports are assumed to require remote-managed PCI devices which means that operators need to tag those as "remote_managed" in the PCI whitelist if this is the case (there is no meta information or standard means of querying this information). The following changes are introduced: * Handling for VNIC_TYPE_REMOTE_MANAGED ports during allocation of resources for instance creation (remote_managed == true in InstancePciRequests); * Usage of the noop os-vif plugin for VNIC_TYPE_REMOTE_MANAGED ports in order to avoid the invocation of the local representor plugging logic since a networking backend is responsible for that in this case; * Expectation of bind time events for ports of VNIC_TYPE_REMOTE_MANAGED. Events for those arrive early from Neutron after a port update (before Nova begins to wait in the virt driver code, therefore, Nova is set to avoid waiting for plug events for VNIC_TYPE_REMOTE_MANAGED ports; * Making sure the service version is high enough on all compute services before creating instances with ports that have VNIC type VNIC_TYPE_REMOTE_MANAGED. Network requests are examined for the presence of port ids to determine the VNIC type via Neutron API. If remote-managed ports are requested, a compute service version check is performed across all cells. Change-Id: Ica09376951d49bc60ce6e33147477e4fa38b9482 Implements: blueprint integration-with-off-path-network-backends
* | | | | | | Merge "Cleanup old resize instances dir before resize"Zuul2022-02-091-0/+6
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | |
View Lorry Controller Status