The default behavior for the "nova-manage cell_v2 map_instances"
command is to map all instances in the cell in batches of 50.
This can be slow when there are several thousand instances in the
deployment and an operator may want to specify a higher --max-count
value and run the command until it completes.
This simply updates the command option description and man page to
point this out for consideration.
Change-Id: I59c2ed89fe02212977445f6825c6da8fedbb8ccf
Related-Bug: #1742649
This change introduces a new microversion which must be used
to create a server from a multiattach volume or attach a multiattach
volume to an existing server instance.
Attaching a multiattach volume to a shelved offloaded instance is not
supported since an instance in that state does not have a compute host
so we can't tell if the compute would support the multiattach volume
or not. This is consistent with the tagged attach validation with 2.49.
When creating a server from a multiattach volume, we'll check to see
if all computes in all cells are upgraded to the point of even supporting
the compute side changes, otherwise the server create request fails with
a 409. We do this because we don't know which compute node the scheduler
will pick and we don't have any compute capability filtering in the
scheduler for multiattach volumes (that may be a future improvement).
Similarly, when attaching a multiattach volume to an existing instance,
if the compute isn't new enough to support multiattach or the virt
driver simply doesn't support the capability, a 409 response is returned.
Presumably, operators will use AZs/aggregates to organize which hosts
support multiattach if they have a mixed hypervisor deployment, or will
simply disable multiattach support via Cinder policy.
The unit tests are covering error conditions with the new flow. A new
functional scenario test is added for happy path testing of the new boot
from multiattach volume flow and attaching a multiattach volume to more
than one instance.
Tempest integration testing for multiattach is added in change
I80c20914c03d7371e798ca3567c37307a0d54aaa.
Devstack support for multiattach is added in change
I46b7eabf6a28f230666f6933a087f73cb4408348.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Implements: blueprint multi-attach-volume
Change-Id: I02120ef8767c3f9c9497bff67101e57e204ed6f4
The nova noVNC proxy server has gained the ability to use the VeNCrypt
authentication scheme to secure network communications with the compute
node VNC servers. This documents how to configure the QEMU/KVM compute
nodes and the noVNC proxy server nodes.
Change-Id: If3cea87568efff0874cd8851cabc6770812c545b
Blueprint: websocket-proxy-to-host-security
Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>
This change set adds Open vSwitch VIF support for the PowerVM virt
driver.
Change-Id: If23aeb890c4365014a9f1262647611162f981f12
Partially-Implements: blueprint powervm-nova-it-compute-driver
When deleting a cell, if there are instance mappings to the cell,
the command fails with the following message.
* There are existing instances mapped to cell with uuid UUID.
But even if all instances have been deleted in the cell,
the same message is shown.
So in that case, add a warning that the instance mappings have to
be deleted by 'nova-manage db archive_deleted_rows'
before deleting the cell.
Change-Id: I2a163fb50a7e71ce9f463bc9ddeffe2ea47d1588
Closes-Bug: #1725331
The cells v2 layout documentation clearly states that there are no
upcalls from cells back to the central API services. This mislead
me for sometime as I could not fathom how a compute node in a cell
was supposed to report its resource info.
It turns out nova looks up the placement service in the keystone
catalogue and contacts it directly which to my mind is an upcall. I
wonder if the author of the not felt that the placement service is
not really part of nova?
Change-Id: If14be8b182f0af4e4e6641046fec638c07e26546
Closes-Bug: #1742421
Document the ``nova-manage cell_v2 list_hosts`` command for listing
hosts in one or all v2 cells.
Change-Id: I46fece55f1647fe7a41906054ad0d6213315187b
Related-Bug: #1735687
This fills in the TODOs for the unit, functional and
docs part of the API contributor guide.
Since we don't rely on the DocImpact tag in the commit
message for API changes (that tag results in a nova bug
and was meant mostly for making changes to docs external
to the nova repo, which is no longer the case), this
changes that section to just talk about the in-tree docs
that should be updated for API changes.
Change-Id: I9ca423c09185d2e3733357fd47aaba82d716eea4
Not only libvirt/KVM driver but also libvirt/QEMU works with cpu
topology feature in nova. So we just update the document.
Change-Id: If8f0229072c8518c9301a872b98862687d93a044
In the comments to I8f0c3006d1bb97d228f73256c58a79235cd12670, a request
for clarification was made on when the last-modified header should
be "now". This adds an example to help things a bit more clear.
Change-Id: I301f17bc7aad9f0037d2b13aa6e493ac9a6abb80
Unlike in nova-manage create_cell, in nova-manage update_cell the check
for the same combination of transport-url and/or database_connection
does not exist. Hence it allows a user to update a cell's transport-url
and/or database_connection to another existing cell's transport/db urls.
Change-Id: Ia5d5566c535d6da3d215392590a2d362e1226424
Closes-Bug: #1729806
Deprecated in Pike:
I660e0316b11afcad65c0fe7bd167ddcec9239a8b
This filter relies on the flavor.id primary key which will
change as (1) flavors were migrated to the API database and
(2) when a flavor is changed by deleting and re-creating the
flavor.
Also, as noted in blueprint put-host-manager-instance-info-on-a-diet,
this is one step forward in getting us to a point where the only
thing that the in-tree filters care about in the HostState.instances
dict is the instance uuid (for the affinity filters). Which means
we can eventually stop RPC casting all instance information from
all nova-compute services to the scheduler for every instance create,
delete, move or periodic sync task - we only would need to send the
list of instance UUIDs. That should help with RPC traffic in a large
and busy deployment.
Change-Id: Icb43fe2ef5252d2838f6f8572c7497840a9797a1
With change I2f367b06e683ed7c815dd9e0536a46e5f0a27e6c, nova-compute
now unconditionally requires Placement 1.14 to be available (the
client side code doesn't check to see if 1.14 is available before
trying to use it).
This change updates the nova-status check for the minimum required
version of Placement and also starts the "Queens" section of the
Placement upgrade notes docs.
Change-Id: I37415e384d375bc9b548a0223f787a9236286bb0
Add some instructions on how and when to add last-modified headers
when creating a new handler in the placement API.
Change-Id: I8f0c3006d1bb97d228f73256c58a79235cd12670
This is a follow up to change I947e927802f755ccb25a91efd82cac895779d19e
to document the decision and agreements made in that change about fixing
obvious regression bugs in admin-only APIs without a microversion.
Change-Id: I4051cb465c509db63620ee727654f7c896fab1e8
Related-Bug: #1733886
quiesce and unquiesce are virt driver and supported in libvirt
we need document those functions into the support matrix
to let admin/user be able to refer to.
Change-Id: If1277cde2aff44b5651154fc05c3cd4377237c60
This adds some links to talks from the Sydney summit to the docs
for cells v2, bug triage, and the metadata service.
While adding a "References" section to the metadata docs, I figured
it was also useful to link to a blog post from mikal about vendordata
since it also includes code samples.
Change-Id: Ifc47a5472db37f5526004d2e00751365a026975a
Add a ``nova-manage cell_v2 list_hosts`` command for listing hosts
in one or all v2 cells.
Change-Id: Ie8eaa8701aafac10e030568107b8e6255a60434d
Closes-Bug: #1735687
Although the document is saying the network provider is neutron,
but the picture still has nova network which is outdated.
Change-Id: I3d33a789a2683eea235c5b5c0a2336b7b51da795
Closes-Bug: #1734841
Zuul