Keystone project manager role can be used for the project-level
management APIs. Nova introduced the manager role in policy
defaults.
To introduced the manager role, we need to make migrations
policies more granular. Adding the separate policies for host
related operation allow us to open the migration operations
to project manager role. Existing policy is checked if migration
without specifying host and new policy is checked if host is
specified. Same will be applied to list migrations, new policy
will control to return the host info.
Also, Adding doc and releasenotes.
Partial implement blueprint policy-manager-role-default
Change-Id: Ie7d135e4d24ac6d53c46a4c69ade0b0bda554e71
Signed-off-by: Ghanshyam Mann <gmaan@ghanshyammann.com>
Signed-off-by: ghanshyam <gmaan@ghanshyammann.com>
As part of the this BP[1], we are going to add the
Project Manager role as default in API policies.
This commit adds the project manager role context
in the policies unit tests so that when we change
the policy default to project manager then we can
know how the changes/permission will looks like.
NOTE: This does not change any policy default, only
adding manager context in existing unit tests.
Partial implement blueprint policy-manager-role-default
[1] https://blueprints.launchpad.net/nova/+spec/policy-manager-role-default
Change-Id: Ib1622e7593108aa4fac65fcc34cb616502abed94
Signed-off-by: Ghanshyam Mann <gmaan@ghanshyammann.com>
For each lifecycle operation nova re-load, parses, and validates the
[pci]alias config option. This is wasteful. So this patch adds
functools.cache decorator on the function used to do this work.
Change-Id: If2ffb25430749a22c923c0938221833e7b883873
Both nova-api and nova-compute depends on the [pci]alias configuration.
These services loaded and validated the config lazily when it was
needed. This can late and hard to troubleshoot failures during instance
lifecycle operations due to simple config errors.
So this patch adds an early load of this config to nova-api and
nova-compute.
Related-Bug: #2102038
Related-Bug: #2111440
Change-Id: I5d5dc912ca24979067984c7cb53ceaded7daf236
Either the vendor_id and product_id needs to be set or the
resource_class needs to be set in each alias. This is now validated when
the alias is parsed to avoid late failure during placement
allocation_candidates query.
Closes-Bug: #2111440
Change-Id: I7fd43b3d6faac8c4098b0983e8adc596414823a1
Document and the limitation of the PCI in Placement feature that it
does not support [pci]alias configuration where the name of the alias is
repeated. E.g.
[pci]
alias = { "name": "vf1", "product_id":"10ca", "vendor_id":"8086", "device_type":"type-VF"}
alias = { "name": "vf1", "product_id":"f000", "vendor_id":"8086", "device_type":"type-VF"}
This would mean the alias vf1 can be fulfilled from devices with product
id 10ca OR f000. However this OR relationship cannot be encoded to a
single Placement allocation query as Placement does not support
requesting alternative resource classes for a request[2].
This limitation was encoded in the original PCI in Placement
implementation[1] but we missed to mention it in the doc.
This is now fixed.
[1]https://github.com/openstack/nova/blob/0d484ce37d86e989c8abdf57aec5e334f68206ef/nova/objects/request_spec.py#L504-L528
[2]https://docs.openstack.org/api-ref/placement/#list-allocation-candidates
Related-Bug: #2102038
Change-Id: I9dd78b1498f870a4e4c3f26c23d42d105aec0350
PCI in Placement never supported PCI aliases with multiple specs, i.e.
when an alias name is used in multiple alias definitions. The code
raised ValueError late and without a proper error message. Now
PciInvalidAlias with a descriptive message is raised instead.
Closes-Bug: #2102038
Change-Id: Id1407a37dc5ddad22d8dbf7d589ed998ffc2804e
* Address an off-by-one error: the cpu_info field was modified in v2.28,
not v2.27,
* Correct the api-ref to indicate that the 'servers' field is not
actually required and will be missing if '?with_servers=false', while
the 'name' and 'uuid' fields of servers entries *are* required.
* Clarify a comment about the above in the schemas.
* Uncouple the '_hypervisor_response' and '_hypervisor_detail_response'
helper schemas. The minor increase in lines of code is worth it for
the decrease in complexity.
* Add the 'host_ip', 'hypervisor_type', and 'hypervisor_version' fields
to the list of required fields for "detail"-style responses (show and
detailed list).
* Make the 'current_workload', 'disk_available_least', 'free_disk_gb',
'free_ram_mb', 'host_ip' and 'running_vms' fields of the hypervisor
"detail"-style responses nullable, and the 'current_workload',
'disk_available_least', 'free_disk_gb', 'free_ram_mb' and
'running_vms' fields of the deprecated statistics API nullable.
Change-Id: Ibe55b44e65fe17141c63cceae8a003816ffe4f23
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The user_id and project_id fields can be null. Explain why.
Change-Id: I34353ec7e55845a83f5e2f1dc4b41dead4ac5c81
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
In c12eebd4c6 we missed that there are
another set of config option that become unused now. So this is a follow
up patch to remove those as well.
Change-Id: Ie00805b5f72b118db134aeb8399ef4c72f434966
This removes the script from our contrib directory now that it is
moved to https://opendev.org/openstack/nova-contrib
Change-Id: I09c3b3e73f8b6bcb4223bed20c456bb582b55bcd
The doc is now clarifying that [filter_scheduler]pci_in_placement needs
to be set to nova-api, nova-scheduler, and nova-conductor config as
well.
Closes-Bug: #2112303
Change-Id: I3c7be2f109a97ef5cc4b2dc76cb7c58ef8c68afa
Due to glance behavioral changes, using the new location API causes
async hashing jobs to create confusion for tooling not expecting
undeletable images.
Revert this until glance can resolve the issue.
This reverts commit eab0de2900.
Change-Id: Ifc4631720a1872cb6d93e9ee490c19edd1a7b98e
The _create_ephemeral() method is responsible for creating ephemeral
disks with image type "raw" and formatting them with mkfs. In the case
of [libvirt]images_type "qcow2", _create_ephemeral() will create
backing files.
Currently we are not using a consistent naming convention for choosing
the filesystem label for ephemeral disks. When we create a server for
example, we go through the disks and label them "ephemeral0",
"ephemeral1", "ephemeral2", etc.
When we hard reboot a server, there is a check to create missing
backing files and if so, a new backing file will be created but instead
of being labeled "ephemeralN" the code attempts to label them with the
name of the backing file itself for example "ephemeral_1_40d1d2c". This
will fail if the filesystem used for ephemeral disks has limitations on
the length of filesystem label names (VFAT, XFS, ...). For example:
mkfs.vfat: Label can be no longer than 11 characters
This adds a helper method for obtaining ephemeral disks filesystem
label names and uses it the same way in the few places fs_label is
specified.
Closes-Bug: #2061701
Change-Id: Id033a5760272e4fb06dee2342414b26aa16ffe24
Ghanshyam Maan