This was a great tool but it seems it is no longer maintained, with no
commits since late 2021 [1]. Remove it, capturing static copies of the
SVGs it was generating so we don't lose information. The original
"source" is retained in case we ever want to revive our use of the tool
but that seems unlikely at this point.
[1] https://github.com/blockdiag/blockdiag
Change-Id: Ie3f89730128fdb8beca8bb02312d11516affcbbc
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
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
* Fix warnings when executing 'tox -e docs'.
* Fix consistency for expressions of REST APIs.
* Remove 'json' in some code-blocks
because the contents include comments
so they are not in accordance with JSON format.
* Add the '-W' option in the sphinx-build command
for the docs target.
Change-Id: Iaaa4e2444030622539a61055e114a649466be497
This moves the completed Stein specs to the implemented directory and
adds the redirects. This was done using:
$ tox -e move-implemented-specs stein
This also removes the stein-template symlink from the docs.
And renames the handling-down-cell_new.rst spec to handling-down-cell.rst
to match the blueprint.
Change-Id: Id92bec8c5a2436a4053765f735d252c7c165f019
The spec is updated based on what was implemented during the Stein
cycle.
Change-Id: I52424adf73756823aee81a1a32329f6c8f131c22
blueprint: bandwidth-resource-provider
"Filter Allocation Candidates by Provider Tree" spec has been approved
proposing the new "in_tree" queryparm, but it didn't address how it
works with the granular requests using "in_tree<N>" syntax.
This patch updates the spec to clear it out.
Change-Id: I2726b1b1a632ef3627af872c150ed6564e65b108
Blueprint: alloc-candidates-in-tree
This is a followup that addresses comments from change
Ib86a7994d7a577b8e6a2dd32f4fcf12b7f788af8 and fixes the code block
formatting for a pseudocode section.
Related to blueprint count-quota-usage-from-placement
Change-Id: I7c9e490a2f614c5ea6f85d2ed70fa35dd0c81417
As discussed in Berlin Summit, there are some
considerations should be added to the design:
1. Expose ``boot_index`` in this feature could
make it easier for users to detach and attach
volumes[1].
2. As discussed in Maillist[2], we are not going
to allow detach/attach volumes for instance in
states other than STOPPED,SHELVED/SHELVE_OFFLOADED
so we make it clear in the spec.
[1] https://etherpad.openstack.org/p/BER-bfv-improvements
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001344.html
Change-Id: I0a03d4840e83cd01f3d546ed0517105dcb6e5328
- This change introduces a spec to describe
extension of the nova libvirt driver to
support live migration of guests with
SR-IOV interfaces.
blueprint libvirt-neutron-sriov-livemigration
Change-Id: Ic2650ec51f9f97f3db3dbda049863ce2c538af34
This spec present numa information in server diagnostic API.
APIImpact
Change-Id: I36872473a569f3c8bb0f835d0e2c725c7764d69c
bp: show-server-numa-topology
SmartNICs allow complex packet processing on the NIC. In order to
support hardware acceleration for them, Nova core needs modifications
to support the combination of VIF and vRouter plugging they support.
This spec proposes a hybrid SR-IOV and vRouter model to enable
acceleration.
Change-Id: If4c2795d33dbd701582bfb8ea5aa4b14f4e69341
Signed-off-by: Jan Gutter <jan.gutter@netronome.com>
blueprint: vrouter-hw-offloads
Add support for providing unique per-instance serial numbers to servers.
Spec for blueprint per-instance-libvirt-sysinfo-serial
Change-Id: I819b888e5c6cae8fc8898489815dbe2254d33fe7
In Pike, we re-architected the quota system to count actual resource
usage instead of using reservations and tracking quota usages in a
separate database table. We're counting resources like instances, CPU,
and RAM by querying each cell database and aggregating the results per
project and per user. This approach is susceptible to undesirable
behavior if a cell becomes unavailable. If a cell becomes unavailable,
resources in its database cannot be counted and will not be included in
resource usage until the cell returns. Cells could become unavailable
if an operator is performing maintenance on a cell or if a cell
database is experiencing problems and we cannot connect to it.
We can make resource usage counting for quotas resilient to temporary
cell outages by querying placement and the API database for resource
usage instead of reading separate cell databases.
Spec for blueprint count-quota-usage-from-placement
Change-Id: Ib86a7994d7a577b8e6a2dd32f4fcf12b7f788af8
Expand resize (cold migration) support across multiple cells.
Spec for blueprint cross-cell-resize
Change-Id: I3f89324f1876e3313e8dce73057f7aed0396e432
The AMD SEV spec was just merged, but there were a few minor nits
outstanding, so address them here.
blueprint: amd-sev-libvirt-support
Change-Id: I93840aa852b837c03ede9e21e720c1e1c1c773f2
Currently we uses cpu_model in nova.conf (when cpu_mode is set to
‘custom’) to specify the CPU model the instance should use on this host.
This could have implications on availability of compute nodes for live
migration if you ended up with an "advanced" CPU model when all you
really cared about was an older feature flag.
To mitigate the problem , we use cpu_models to replace cpu_model, where
cpu_models is an ordered list of CPU models the host supports. The list
is ordered so that the more common and less advanced CPU models are
listed earlier. End users specify CPU features they required through
traits, libvirt driver then select the first one in the list that can
provide the required feature traits. This would make it more likely that
the instance could be live-migrated later on.
blueprint: cpu-model-selection
Change-Id: I546230ac115eb3de14eac25b9dd0c74aafdaccd5
Signed-off-by: Jack Ding <jack.ding@windriver.com>
Validate the combination of the flavor extra-specs and image properties.
If validation failed then synchronously return error to user.
blueprint: flavor-extra-spec-image-property-validation
Change-Id: Ic1c5b28f6f58c07744eb193faef1b52c7ecfe693
Signed-off-by: Jack Ding <jack.ding@windriver.com>
This spec proposes work required in order for nova's libvirt driver to
support launching of KVM instances which are encrypted using AMD's
SEV (Secure Encrypted Virtualization) technology:
https://developer.amd.com/sev/
blueprint: amd-sev-libvirt-support
Change-Id: Id7581365941ad40762a4732c33d359cfa75089fa
This spec details changes to os-vif to support a more generic datapath
offload model by using composition instead of inheritance.
Change-Id: I9757ffc2429de3a682d1e361ab592eb6eeca173b
Signed-off-by: Jan Gutter <jan.gutter@netronome.com>
blueprint: generic-os-vif-offloads
This feature adds support for the PENDING server state. Instead of
setting a server to the ERROR state when the Placement returns no
valid hosts for the requested server, the PENDING state is used if
the operator wishes so. This will allow the execution of subsequent
actions transparently to the end user.
Change-Id: Ie2989dee31a8d7242bf5b78019f016b3bc7e42a3
Implements: blueprint introduce-pending-vm-state
Filter Scheduler uses the so-called weights during its work. A weigher
is a way to select the best suitable host from a group of valid hosts by
giving weights to all the hosts in the list.
In the current implementation, the weights are controlled by config
options like [filter_scheduler]/cpu_weight_multiplier.
The total weight of a compute node is calculated by combination of
several weighers:
weight = w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ...
As it is controlled by config options, the weights are global across the
whole deployment, and this is not efficient enough for operators.
This spec proposes to be able to override the weight configuration
options using aggregate metadata to provide a more fine-grained
control over resource weights.
Change-Id: I8270f3a51260c2e8fbbbb4f9c179729a28d138ef
Implements: blueprint per-aggregate-scheduling-weight
Presently, it is allowed to rebuild servers in ERROR state, as long
as they have successfully started up before.
If a user tries to rebuild an instance in cell0, the request fails
with an exception of type InstanceInvalidState.
This spec summarizes the changes needed to enable the rebuilding of
instances that failed during creation.
Change-Id: I3cf92b987da014e8b01f8b1a3f774b03ce3bb0b7
Implements: blueprint enable-rebuild-for-instances-in-cell0
Continuing the work in Rocky to support NUMA live migration, this
version of the spec changes and clarifies some things related to
placement, claiming resources, and how the destination communicates
with the source.
Part of bp numa-aware-live-migration
Change-Id: I6a90eff7118de3e3f69b8c60da5d8beb38b60970
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The spec is describing the operation of rebuild the volume-backed
server with a new image.
Spec for blueprint volume-backed-server-rebuild
Change-Id: I646041c872c4172219df2527820a672a0a2cb736
This spec proposes using ironic's conductor group feature to limit the
subset of nodes which a nova-compute service will manage. This allows
for partitioning nova-compute services to a particular location
(building, aisle, rack, etc), and provides a way for operators to manage
the failure domain of a given nova-compute service.
Change-Id: I62b838ee5fc56d97fdd35d620dd76d50606d0f34
Implements: blueprint ironic-conductor-groups
Stephen Finucane