openstack/nova-specs - nova-specs - OpenDev: Free Software Needs Free Tools

Many instances filter are restricted to admin-only users, while the
related attribute are readable when showing instance detail for non
admin users.
In order to stay coherent, all existing instance filters who are
related to a field readable by default to non admin users when showing
instance details, should be allowed by default without policy
modification.
APIImpact
Change-Id: I288e4a2bd12702a1e7f7ebed544c95eb4a40e641
Implements: blueprint non-admin-filter-instance-by-az

Based on feedback from the mailing list [1] and changes during
implementation. Key changes:
- We don't require an operator set both 'cpu_shared_set' and
 'cpu_dedicated_set'. Clarify why this is the case.
- Add an upgrade summary and summaries to each upgrade step, since this
 is by far the hairiest part of the whole exercise.
- Replace references to an optional prefilter with the scheduler
 aliasing with optional fallback functionality actually used
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/thread.html#7084
Change-Id: I468abe984d81c264a588f23d4b3804106339a597
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Blueprint: cpu-resources

This spec is for telling libvirt how to manage multiple vGPU types.
The only modification to the approved spec in Stein is to mention
another alternative and no longer mention upgrades since GPUs are
already modeled as children RPs.
Change-Id: Ib125c9de60ac614b4b8cb3ad0f03a4141efd0d2a
Partially-Implements: bp/vgpu-multiple-types
Previously-Approved: Stein

Building on I253faf65a64df11a671446d519626c5fd67ed151 this spec will
outline how BFV instance rescue can also be supported by Nova.
APIImpact
Partial-Implements: blueprint virt-bfv-instance-rescue
Change-Id: I1a7b6386a42a4520c298c18394636053ce28b1d8

Live migration with virtual persistent memory is supported by QEMU
and Libvirt. This spec seeks to enable this support in OpenStack Nova.
Change-Id: Id83c2dbd69080623958bb0044e5e1dfa0e3e1dfa
Implements: blueprint support-live-migration-with-virtual-persistent-memory

There are a class of applications which expect to use a TPM device to
store secrets. In order to run these applications in a virtual machine,
it would be useful to expose a virtual TPM device within the guest.
This spec describes adding flavor/image properties which cause such a
device to be added to the VM.
Blueprint: add-emulated-virtual-tpm
Change-Id: I299903a5f3b3741cb2b2d0271087c263552d4134
Previously-approved: train
Previously-approved: stein

OpenStack is dropping the py2.7 support in ussuri cycle.
specs repo either has py27 job or requirement or tox env.
Ussuri Communtiy-wide goal:
https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html
Change-Id: I7635a0bf7db567d91ae2096a08c48330e8af0ad0

With change I711e56bcb4b72605253fa63be230a68e03e45b84 we
decided to *always* cast from the API to conductor for
resize/cold migrate regardless of same or cross-cell just
to be consistent so this removes the part of the spec that
said we'd just cast in the cross-cell case.
Part of blueprint cross-cell-resize
Change-Id: I4ccd346b2f9b90c61baff4391ef012b8dfa0f07e

Keep the spec consistent with real implementation. The VPMEM feature is
Libvirt and QEMU specific now,so the original design about data model is
deprecated. New 'resources' field is introduced to store different kind of
specific resources, we move to using it to enable virtual persistent memory
in Nova. Besides, we give up vpmem data migrating during resize.
Change-Id: I370a8e299319234bf78e728db4ad3e83df81cbd0

During implementation it was found that there is no reliable method
to identify identification conflicts between actual UUID/NAME and
UUID:$COMPUTE_NODE before the point at which we cannot allow the loading
process to fail. Since the spec previously required failure on an
identification conflict, I am proposing this change to allow for the
use of both by ignoring $COMPUTE_NODE entries if a UUID/NAME record
also exists.
Change-Id: If64509785675442ed9e8e8e452bf7dac837c1953
Blueprint: provider-config-file

This will provide the ability to indicate that the rescue disk image
should be attached as a transient disk device (ie USB stick), so that
existing storage attached to an instance doesn't change its device
address during rescue mode.
Previously approved for Mitaka and Newton.
Change-Id: I253faf65a64df11a671446d519626c5fd67ed151

This spec adds two new image/flavor properties
to allow spcifying a NUMA affinity policy for
PCI devices including neutron SR-IOV interfaces.
blueprint: vm-scoped-sriov-numa-affinity
Change-Id: I66b556025ee2f704b91be1249d793e2eeaa1d891

Previously-approved: Train
Spec for blueprint policy-defaults-refresh
Change-Id: I55b9490178dd215eb6e9f7d1f48e28f3eeaec63d

https://review.opendev.org/#/c/688042/ has already done the TODO
mentioned in
https://review.opendev.org/#/c/685857/3/specs/ussuri/approved/add-user-id-field-to-the-migrations-table.rst@213
Change-Id: Ibbfa7548d00b762fc4971f5ecf9c6f1c7694caae

Add a mandatory 'Feature Liaison' section to the spec template,
requiring specs to be sponsored by an experienced nova developer (not
necessarily an actual core -- this is explained in the docs).
This in an effort to mitigate several problems noted in previous
development cycles:
- Inexperienced contributors don't understand how nova dev culture works
- "Nobody but me cares about my feature"
- "Whom should I ask for reviews first, especially if I don't even know
 whether I'm ready for them?"
The current commit edits already-approved specs to include the new
section.
The main README is updated with a new section to describe more
thoroughly what this feature liaison thing is. At the same time, since
this impacts several aspects of the process, the remainder of the README
is tweaked and updated accordingly. Of note:
* We're now going to make distinct use of the launchpad blueprint's
 "Definition" and "Direction" fields. As such, we can still decide to
 defer a blueprint whose spec is merged in the 'approved' directory.
 (Which really isn't different than what we were doing before; it's
 just that now we can do it for reasons other than "oops, this didn't
 get finished in time".)
* The single-core-approval rule for previously approved specifications
 is removed [1].
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019年10月03日.log.html#t2019-10-03T16:08:05
Change-Id: Ibb3a2990e23aecf3ea7ebc1b47413396b676f2d6

Change-Id: I673aaee8672cb76fc0daff73850ce74d754721f5

Since microversion 2.72 nova supports creating servers with neutron ports
having resource request. Since the Train release nova also supports cold
migrating and resizing such servers. However other move operations like live
migration, evacuation and unshelve are still not possible due to missing
resource handling implementation in nova.
The main content of this spec was previously proposed and approved in
Train but only partially was implemented. So this spec proposes only the
still missing pieces.
Blueprint: support-move-ops-with-qos-ports-ussuri
Change-Id: Ife73544f997c71f7840e0f772ca6a7870a8df69e

Nova supports caching images on demand at the compute node level for
performance reasons, but provides no ability to schedule that activity
before a rollout or maintenance window. This long-requested feature
becomes even more important when considering Edge Computing
environments, limited bandwidth, as well as high-scale rapid
application deployment.
APIImpact
Related to blueprint https://blueprints.launchpad.net/nova/+spec/image-precache-support
Change-Id: Ice4d23b1397e97d4f39a9d8c9f01ee2ac1534ce0

Change-Id: Ib17233684977eff545c2c8326f01adc84560a066

Describes the Nova - Cyborg interaction needed to create and manage
instances with accelerators, and the changes needed in Nova to
accomplish that.
No changes from Train version except History.
Previously-approved: Train
Change-Id: I42d1829ab02db5f927a6bd63235cec667d416264
Blueprint: nova-cyborg-interaction

This is a proposal to get rid of Nova's use of python-${service}client
for $service in glance, ironic, neutron, cinder, etc and replace them
with the OpenStack SDK.
Change-Id: I256a43c12a0fd7cf30d7a077616a14dd236a93f7
Previously-approved: Train
Implements: blueprint openstacksdk-in-nova

This is a trivial resubmission of the image metadata prefiltering spec
which was deferred prior to feature freeze due to merge conflicts
with priority features such as SEV and PCPUs in placement.
Blueprint: image-metadata-prefiltering
Previously-approved: Train
Change-Id: Ic56a62bd734620cbef06da713876768e8dfa9a8f

This is a proposal to configure resource provider visibility, ownership,
inventory, trait, and aggregate settings using a standardized YAML file format.
This was previously approved in Train [1] but did not make it into the
release.
[1] http://specs.openstack.org/openstack/nova-specs/specs/train/approved/provider-config-file.html
Previously-approved: Train
Blueprint: provider-config-file
Change-Id: I4443a600d009f7085813e2c21d77dc491bbdd1c6

Previously-approved: Stein, Train
Spec for blueprint cross-cell-resize
Change-Id: I9a81b8eb5b21622129a07e33b211a912eb1e483e

The spec is updated with the 's/forbidden/isolated/' for more appropriate
naming:
* Placement pre-request filter renamed to 'isolate_aggregates'
* A new config option renamed to 'enable_isolated_aggregate_filtering'
Change-Id: I5fd1d68c89a85bf0edaca214677819f359f048d9
Implements: blueprint placement-req-filter-forbidden-aggregates

The blueprint proposes tracking the user_id and project_id of the user that
initiated a server migration and exposing those values in the API.
Previously-approved: Train
Blueprint: add-user-id-field-to-the-migrations-table
Change-Id: I23babc6379fb0602c28337d30b7298bb526802b8

Update the spec to reflect what was actually implemented.
TL;DR is during implementation, we found that the old limit in the
libvirt driver of 26 was a limit on the maximum number of disk
devices allowed to attach to a single instance, including the root
disk (and any other disks). So "volumes" wasn't really correct for
representing what is being limited and the terminology was changed
to "disk devices".
Related to blueprint conf-max-attach-volumes
Change-Id: I3152d0ed64709495ff7f13ff1d75ce62558a8731

Change-Id: I7913fc0bd027d883d11910ec26c007fb8868d404

Add an anchor for the section of the AMD SEV spec which covers various
approaches to memory reservation, so that the incoming feature
documentation can deep-link to it.
Change-Id: I63e62d6d11ed1de51548ac196dc495b464e652d3