Accept forbidden traits in the processing of extra_specs, with the
format of:
trait:CUSTOM_MAGIC=forbidden
This will be transformed into required=!CUSTOM_MAGIC when the traits
are assembled into a request to GET /allocation_candidates.
Implements blueprint forbidden-traits-in-nova
Change-Id: I31e609aef47d2fea03f279e4bfdd30f072d062b4
currently we have following output:
$ curl http://169.254.169.254/openstack
2012-08-10
2013-04-04
2013-10-17
2015-10-15
2016-06-30
2016-10-06
2017-02-22
latest
Change-Id: I6b4aed63d5c981abc9374baf929f05b26760e645
Everyone seems to agree that the only sane ordering of these operations
is "api first, cell after." However, grenade and our own documentation
shows the api database as coming after the main one. I believe this
was added to grenade in a sort of append operation, and thus after the
main database. This was done back when usage of the API database was
still optional (for upgrades) and thus the ordering didn't matter much.
Since the process has been correct (api first) in devstack for a long
time, and since grenade runs after devstack, we haven't had any issues.
A recent change to add something to a core data structure column format
highlighted the out-of-order-ness of this.
I also believe the docs got the same append behavior when adding the
command to the list, and/or it may have been copied from grenade, which
is our in-code manifestation of the upgrade steps.
Change-Id: I19f263ed314a8b01bbb07337467392cc1c146b66
Related-Bug: #1761775
this document is out of date since a set of changes made such as
43f91a87cb39f6159bde8be8d02aa7
Put those 'to be fixed in queens' make people think it should
be already been fixed due to queen release, so remove them in order
to avoid confusion and we can continue to enhance this doc.
TrivialFix
Change-Id: I12dd385f4e1f159bdb9a78a629d4095889397c09
This adds the ability to hotplug network interfaces for the powervm
virt driver.
Blueprint: powervm-network-hotplug
Change-Id: I78b94c9731c35e3291d46b9bf9f5554e21c2429e
It has long been *recommended* that the placement service be upgraded
before nova services, but scenarios where it isn't have never really
been explored or tested. Following (yet another) discussion on the
topic [1] it was decided that we are best served by *requiring* that
placement be updated first. This simplifies our test/support matrix,
and the code we write to consume placement. It also makes the operator
experience cleaner by giving them a clear and unambiguous script to
follow.
This change set rewords the upgrade document accordingly.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-03-26.log.html#t2018-03-26T17:35:11
Change-Id: I97215e94efdd8c05045872fb9ba7d2089dc6efb8
The metadata service docs were hard to find since they were nested
down in some nova-network admin guide docs, and they were a mix of
end user and admin deployment guide information.
This change splits out the end-user facing content into a user
guide and leaves the deployment-specific information in the admin
guide, and links are updated appropriately.
The admin guide portion also referenced some config options that no
longer exist, so those are also removed and vendordata_providers
is added with a link to the vendordata guide. The options themselves
are cleaned up for their current groups and linked to the config option
docs.
Change-Id: I66035366f3a7ca62ea12d6afa74d13db01ec9f8d
The filter-scheduler doc was pretty old and I was recently asked to give
some guidance on how to create a custom filter.
A doc is better than any chat, so let's make that better.
Change-Id: I64d24fb4337bb8c1e59a04818307b43f181e2ad2
The feature classification effectively died with OSIC, so
let's remove the warning from the page as it's actively
maintained.
Change-Id: I6e601759f6e26d2c9b94229be953490a8342709a
The docs were using variable names from the filter code rather
than the actual config options.
Change-Id: I2694b32e9c90ad098101e41e4e3ae36ddafd8d0f
Related-Bug: #1746483
Nova has two pages in documentation listing things supported on several
architectures/hypervisors. This patch adds initial state of AArch64
into support matrix.
Document minimal qemu/libvirt for aarch64. Version 3.6.0 was first one
which worked for us with Nova without a need for extra patches.
Change-Id: I2ee7be9e88e20ed0f77be07fed4fdd800533b3c5
The affinity and anti-affinity server group policy is enforced by the
scheduler but two parallel scheduling could cause that such policy is
violated. During instance boot a late policy check was performed in
the compute manager to prevent this. This check was missing in case
of rebuild. Therefore two parallel evacuate command could cause that
the server group policy is violated. This patch introduces the late
policy check to rebuild to prevent such situation. When the violation
is detected during boot a re-scheduling happens. However the rebuild
action does not have the re-scheduling implementation so in this case
the rebuild will fail and the evacuation needs to be retried by the
user. Still this is better than allowing a parallel evacuation to
break the server group affinity policy.
To make the late policy check possible in the compute/manager the
rebuild_instance compute RPC call was extended with a request_spec
parameter.
Co-Authored-By: Richard Zsarnoczai <richard.zsarnoczai@ericsson.com>
Change-Id: I752617066bb2167b49239ab9d17b0c89754a3e12
Closes-Bug: #1735407
Now that Queens supports attaching virtual GPUs to an instance, we need to
properly document which hypervisors support that, how to use that feature and
what the existing caveats are.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Change-Id: I871894c3584e92f80f6420dfc009e21b30450f8e
Implements: blueprint add-support-for-vgpu
This updates some busted links, adds ironic and powervm to the
table header, and copies a description from the admin guide.
Change-Id: If146a26a8d0c66a3ff218c62624e3a130744dde5
The instance list performance and reschedules issues have
been fixed in Queens so this updates the caveats section
of the cells v2 layout doc to point out those changes since
Pike.
Change-Id: I882f185554b6d2781534fa93e41e5010ea3a641d
Now that the instructions for booting from a volume
have been migrated to nova, the instructions for
booting from an encrypted volume can be added as
well.
This commit adds instructions for how to import an
image into an encrypted volume.
Closes-Bug: 1701614
Change-Id: Ida4cf70a7e53fd37ceeadb5629e3221072219689
This adds a mention of the nova-scheduler service requiring
placement 1.17 and also links to the placement upgrade notes
from the more general upgrade notes, since we are now firmly
in a place where placement needs to be upgraded before nova.
Since we consider placement global, this removes the 1.14
note about nova-compute since we assume that if you're going
to upgrade placement to get 1.17 for the scheduler, and control
services should be upgraded before computes, then the computes
are going to get a new enough placement service automatically.
Change-Id: I06937c7642dca4a1932cbbf46569acc9c58e44a6
This is a follow up to Ie039322660fd0e2e0403843448379b78114c425b.
A few things are changed here:
* The note about using file injection is removed. File injection
was deprecated in the API in Queens and not something that we
really want users using.
* Mention that creating a flavor is typically admin-only.
* Link to the BDM docs for more details about BDM parameter values.
* Update the manage-ip-address docs to make the examples rely on
using the networking resource CLIs rather than any proxy APIs
that were available in nova.
Change-Id: Ifa2e2bbb4c5f51f13d1a5832bd7dbf9f690fcad7
This imports the "launch instance" end user guide docs from
the openstack-manuals repo. As part of the docs migration
in Pike, these were forgotten. The copied contents come from
the stable/ocata branch of openstack-manuals, and therefore
likely need some updating, but that could be done in follow up
changes. This is an initial import to (1) publish the content
again somewhere and (2) fix broken links in the cinder docs
for booting from volume.
Change-Id: Ie039322660fd0e2e0403843448379b78114c425b
Partial-Bug: #1714017
Related-Bug: #1711267
This takes most of the release note and adds it to the user
flavor docs which is more discoverable for an end user.
Change-Id: Ia83af4dfcc0c040679b0d0cd5282830fca27bd63
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
This change set adds Open vSwitch VIF support for the PowerVM virt
driver.
Change-Id: If23aeb890c4365014a9f1262647611162f981f12
Partially-Implements: blueprint powervm-nova-it-compute-driver
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
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
Chris Dent