This adds config options for unified limits quotas that allow
admin/operators to specify which resources they will require or ignore
to have unified limits set in Keystone.
The options are only used when ``[quota]driver`` is set to
``UnifiedLimitsDriver``.
When the resource strategy is set to 'require' (the default), the
resource list will represent the resources that are required to have a
registered limit set in Keystone.
When the resource strategy is set to 'ignore', the resource list will
represent the resources that will be ignored for quota enforcement if
they do not have a registered limit set in Keystone.
Related to blueprint unified-limits-nova-unset-limits
Change-Id: Icb08fadbdbf9c1bf354c3091f05edce80ebf68c3
The intended action of this patch is to eliminate the mappings of shares
associated with an instance once the instance is deleted first.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Change-Id: I920266e5ff1397f6324344e21c56e243e9f02417
The purpose of this patch is to ensure that, in the event of a compute
reboot, shares associated with instances are mounted successfully on the
compute host during the service initialization process.
To use Manila as an admin, it is necessary to have a Manila section in the
"nova.conf" configuration file. As a result, the dependencies below have
been introduced in DevStack to satisfy this requirement.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Change-Id: Ia498c72e1d79e98e4d50e2337a5acc4921910f06
This patch does multiple things:
1) Extends the virt interface to pass share_info down to the driver an
update the signatures in all in tree drivers.
2) Extends the compute manager to pass the share_info to the driver at
certain actions.
3) Implement the share_info handling in the libvirt driver.
3.1) Checks requirements for shares and reports the new capabilities
COMPUTE_STORAGE_VIRTIO_FS and
COMPUTE_MEM_BACKING_FILE to signal that.
3.2) Implements mount / unmount.
4) Changes the scheduler to request new capabilities.
Manila is the OpenStack Shared Filesystems service.
These series of patches implement changes required in Nova to allow
the shares provided by Manila to be associated with and attached to
instances using virtiofs.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Depends-On: https://review.opendev.org/c/openstack/os-traits/+/832769
Depends-On: https://review.opendev.org/c/openstack/manila/+/926491
Change-Id: I3a4bca7f03cfa9a1bc20f3f9937bb9b44fe2cde3
When a user asks nova to attach a manila share to the user's instance
nova should use the user's keystone token to talk to manila so that
manila can verify if the user has access to the share.
Manila is the OpenStack Shared Filesystems service. These series
of patches implement changes required in Nova to allow the shares
provided by Manila to be associated with and attached to instances
using virtiofs.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Change-Id: I793f0518dcfffd2286e7bc685cab76794aece91d
This patch is inspired by /nova/volume/cinder.py, it is an abstraction to
the manila service.
Manila is the OpenStack Shared Filesystems service.
These series of patches implement changes required in Nova to allow the shares
provided by Manila to be associated with and attached to instances using
virtiofs.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Depends-On: https://review.opendev.org/c/openstack/openstacksdk/+/889519
Change-Id: I44ab37ec2c15fcfc351c42216660bda39461b163
At least those that don't return bodies (plus rescue, which is easy)
since they're tedious but simple, thus providing a good test ground for
this effort.
Change-Id: I78003b1d2c1515e5fd5e17405df6a219878bdb8a
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This update adds a constraint between instance_uuid and share_id to
make sure it will be unique. It aims to avoid potential conflicts
from simultaneous API creation requests, which could result in the
creation of duplicate records in the database.
Manila is the OpenStack Shared Filesystems service. These series
of patches implement changes required in Nova to allow the shares
provided by Manila to be associated with and attached to instances
using virtiofs.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Change-Id: I419fd40baf9acf487154eebc77c181633ea53272
This update introduces the "attaching" status, which indicates
the beginning of a connection between a share and a server. When
this occurs, the compute system will permit a policy to connect
the share through Manila and will record this connection in the
share_mapping table. Once completed, the status will transition to
"inactive." Additionally, the "detaching" status has been added to
indicate the end of a link between a share and a server. During this
process, the compute system will revoke the share's policy and delete
its entry from the share_mapping table.
Manila is the OpenStack Shared Filesystems service.
These series of patches implement changes required in Nova to allow the shares
provided by Manila to be associated with and attached to instances using
virtiofs.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Change-Id: I1724940474b2e96e0c3962095f77df55c749529a
This makes 'nova-manage limits migrate_to_unified_limits' scan the API
database for flavors and detect if any resource classes are missing
registered limits in Keystone.
Related to blueprint unified-limits-nova-unset-limits
Change-Id: I431176fd4d09201c551d8f82c71515cd4616cfea
olso.policy 4.5.0[1] changed the config options policy_file
default value to 'policy.yaml', which means it is changed
for all the OpenStack services and they do not need to
override the default anymore.
NOTE: There is no change in behaviour here, oslo.policy provides
the same configuration that services have overridden till now.
[1] https://review.opendev.org/c/openstack/releases/+/934012
[2] https://review.opendev.org/c/openstack/requirements/+/934295
Change-Id: I6e4c517eb81a50056563189753b21191bbf6b92d
If a compute is started up while an evacuation of an instance from this
host is still in progress then the destroy_evacuated_instances call will
try to check if the instance is on shared storage to decide if the local
disk needs to deleted from the source node or not. However this call
uses the instance.host to target the RPC call. If the evacuation is
still ongoing then the instance.host might still be set to the source
node. This means the source node during init_host tries to call RPC
on itself. This will always time out as the RPC server is only started
after init_host. Also it is wrong as the shared storage check RPC
should be called on another host. Moreover when this wrongly routed RPC
times out the source compute logs the exception, ignores it, and the
assume the disk is on shared storage so won't clean it up. This means
that a later evacuation of this VM targeting this node will fails as the
instance directory is already present on the node.
The fix is simple, the destroy_evacuated_instances call should always
send the shared storage check RPC call to the destination node of the
evacuation based on the migration record. It will be correct even if the
evacuation is still in progress or even if it is already finished.
Closes-Bug: #2085975
Change-Id: If5ad213649d68da995dad146f0a0c3cacc369309
The numa_policy field in the pci alias supports the same value as the
flavor extra_spec hw:pci_numa_affinity_policy but the config doc was not
updated when the socket value is implemented.
Closes-Bug: #2085824
Change-Id: I997d10638020fc9d60e784e64e395e6e0a9c9430
Makes igb vif model supported for hosts with libvirt 9.3.0 and qemu
8.0.0 or higher.
Implements: blueprint igb-vif-model
Depends-On: https://review.opendev.org/c/openstack/os-traits/+/928582
(merged, released as 3.2.0)
Change-Id: I6a1d8058c640e5dc015889610c4ae864ed9a5ccb
Qemu 8.0 and libvirt 9.3.0 added support for qemu emulated igb
network device. This patch adds the new igb value for hw_vif_model
so nova could eventually support booting VMs with such devices.
Subsequent patches will enable libvirt support.
Implements: blueprint igb-vif-model
Change-Id: I9c8dc1a663d0534d62798c5b4c8d4539551f7ae4
Our tox.ini sets the maximum complexity of a function to be 40. Adding
anything new to the ImageMetaProps.obj_make_compatible push it over the
limit. So this patch factors out common new field value checking logic
to a helper function to reduce the complexity before adding new supported
values.
As there was a small amount of this check in other ovos this patch does
the refactor across all nova ovos.
Change-Id: I828d91196ea06f4dc2823218f036960123446255
Since Hyper-V driver was removed, we don't expect any use case where
nova should be deployed in Windows OS. This scenario is no longer
tested since WinStackers project has been retired.
Drop the remaining code for Windows OS support to reduce unused code
and focus purely on linux systems.
Change-Id: I69b049d13556efe87f4be32f5e6e7f88e42f3b2a
Zuul