As part of the docs migration from openstack-manuals to
nova in the pike release we missed the config-drive docs.
This change does the following:
1. Imports the config-drive doc into the user guide.
2. Fixes a broken link to the metadata service in the doc.
3. Removes a note about liberty being the current release.
4. Adds a link in the API reference parameters to actually
point at the document we have in tree now, which is
otherwise not very discoverable as the main index does
not link to this page (or the user index for that matter).
Partial-Bug: #1714017
Closes-Bug: #1720873
Change-Id: I1d54e1f5a1a94e9821efad99b7fa430bd8fece0a
This adds to the existing warning about forcing a host during
evacuate and mentions how you really really shouldn't be doing
that if the instance is managed by the ironic driver
since those are 1:M with host:node relationships, and since you
can't specify a node when forcing the evacuate, nova will randomly
pick a node from the list for the given host and assign resource
allocations to that node which may already be fully allocated.
Change-Id: I8ae34399d32b2762a67e897807ffa2298e796c4c
The server status values exposed out of the API and used
for filtering when listing instances comes from the values
in nova.api.openstack.common._STATE_MAP. Some of the values
listed in the docs were incorrectly using variable names from
the code, which don't necessarily match the actual value exposed
out of the API.
The compute API server concepts guide actually had this all
correct, so this just updates the API reference.
Change-Id: I30b6f27c6e7fc9365c203b620b311785f8b4b489
Closes-Bug: #1722403
The project_id / tenant_id filter parameters when
listing servers is only applied when the all_tenants
filter is used.
Otherwise if an admin is listing servers and specifies
project_id but not all_tenants, they only get back
instances for the admin's project (in the request context).
Change-Id: I9e8fae8fb86604d7394d0dba4d7c75c3fc93033e
Related-Bug: #1185290
We've had several bugs about this over the years, and until we
actually decide to fix it (or not), we should point out the known
limitation that volume-backed root disks are not replaced during
a rebuild.
Like, if you have a volume-backed instance and rebuild with a new
image, the root disk is still the volume with the original image.
Change-Id: I145cab88f782e4b1e630cc432322bc8436413e71
Related-Bug: #1482040
We already mention the preserve_ephemeral parameter in the request
parameters table, including the note that it's only useful for
baremetal instances, so we don't need to mention it again in the
description of the API.
Also adds a space between some list error codes.
Change-Id: I8712f0fdd06eee1bb9af439621481d1c69b6244c
Nova has a legacy hack to allow admins to specify hosts via an
availability zone using az:host:node. That means ':' cannot be
included in the name of an availability zone itself.
However, the aggregate API accepts requests which have
availability zone names including ':'.
This patch checks the availabilty zone name when aggregate is
created or updated and raises an error if it contains ':'.
Change-Id: I9b0d8e8d4b3ab2cb3d578c22fa259e0e7c0d325b
Closes-Bug: #1695861
The default sort key when listing servers is the
'created_at' field, which is also in the list of
available sort keys in the same description for
this parameter. The 'created' field doesn't exist.
Change-Id: I7a971c421e69cc7a5630454305ee2cddaf0e92d3
Trivial Fix
we have cinder / nova interaction for os-server-external-events
now, add this into introduction chapter.
Change-Id: I17ba89682973d78ce9764300eab50b99b09bf976
Fix AZ related API docs
While we have a big fat comment in the development docs explaining why it's so
terrible to use default AZ values for either booting an instance or setting
an aggregate AZ metadata, we still have confusing API docs that provide the
wrong name for the AZ...
Fixing that and trying to explain the problem within the docs, too.
This reverts commit 92ca21abd61b6df7fc8bc5ffe7502f03b3eca2dd.
Co-Authored-By: Sylvain Bauza <sbauza@redhat.com>
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
Change-Id: Ie4bfe32bbef0f8060bfc0ad4190f262d4a8bd3b2
This reverts commit 71a7eda44b6da00c05bd3e136d0465086c30e721.
This is breaking the gate due to the change in the az name.
Change-Id: Idd7d1aab113f3d4aba8b1deb6e5dc3871a75aa29
Closes-Bug: #1716247
While we have a big fat comment in the development docs explaining why it's so
terrible to use default AZ values for either booting an instance or setting
an aggregate AZ metadata, we still have confusing API docs that provide the
wrong name for the AZ...
Fixing that and trying to explain the problem within the docs, too.
Change-Id: I811d0f219142ca435b2b206e9b11ccd5ac611997
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
Bypassing the scheduler during a live migration or evacuation
is not something we want people to be doing as it can easily fail
if the specified host is already full or doesn't provide something
required by the instance, plus it's a nightmare for tracking allocations
in the Placement service when we're bypassing the scheduler.
Because of this, we should have some warnings in the API reference
about doing this, which this patch adds.
Change-Id: I85e7c2677f4d5eccc1e7f349de06960b53ef148d
When creating a server, you can request security groups and
pre-existing ports, but the security groups are only applied to
any new ports that nova creates, not the pre-existing ones that
the user passes in. This change makes a note of that in the API
reference.
Change-Id: I0ea6891f10f021b0ed752200417e87d7e9bfda31
Related-Bug: #1707319
The 'security_groups' parameter in the GET /os-security-groups API
is not optional and we don't need information about the name
attribute. The "security_groups" parameter being used is actually
for the create server API.
Change-Id: I63bb8fc433b56a3f2b80cfafab37b103fe3a27d9
add description about key_name, which tells user 'null' is not
accepted parameter.
this is ths solution that other than change the code.
Change-Id: Id84c7803fdd44961497cd35c15ece98e2852d4f6
Related-Bug: 1700825
If section reference name is changed not to overlap,
when the 'List Default Quotas For Tenant' API section
is collapsed, it cannot be followed by users.
So the reference is changed to the 'os-quota-sets' chapter.
Change-Id: Ic61b38cabde3b3225f778833f0e7aae6acf5eabc
Closes-Bug: #1705191
'disable-log-reason' API action disable the compute service and
log the disabled reason. But api-ref statement sounds like this API
only log the disable reason.
Correcting description to convey the clear behavior of API.
Closes-Bug: #1702310
Change-Id: I5e1b97ed482d62477d87c96c9914e6f88c041b8b
Because MySQL is case insensitive by default, and this
is something that depends on the database backend in the
cloud, let's not mention that tags are case sensitive in
the API.
Change-Id: I6efa9d6a5c598ac7a5c898d63b6a4b1934560b80
Related-Bug: #1538011
The max_version on the fixed_ips, floating_ips, networks,
security_groups and security_group_members parameters for the
os-quota-class-sets API should be capped at 2.49, not 2.50.
This is a bit confusing but it works the same as max_version
works in the API code, i.e. the max version is the highest
version you can request that parameter on that API and it
will work. 2.50 was wrong because in 2.50 we don't accept
or return those parameters.
This is similar to the network-related resource deprecation
in the os-quota-sets API with the 2.36 microversion. The API
reference for those parameters in os-quota-sets use
max_version: 2.35.
Change-Id: Ib3e3cdc1ba57172fce1b03a0e77302c3edf9f0dc
Closes-Bug: #1705115
There are quite a few changes here as this is not only handling
uuids for the hypervisor id but it's also a refactor in several
APIs for consistency.
The main changes are detailed in the REST API Version History
doc in this change, but to summarize the changes:
* Hypervisor and service IDs are handled as the UUIDs for those
resources; this is necessary for accurately working with these
resources across multiple cells.
* The 'servers' and 'search' routes are deprecated and folded into
the index and detail methods as query parameters, validated using
json schema.
* The show method will also be able to return the list of servers
hosted on the given hypervisor using the with_servers query
parameter.
* The marker used when paging over lists of hypervisors is the
compute node UUID.
* Using the hypervisor_hostname_pattern query parameter will not
work with paging parameters.
* API reference docs are updated for the detailed changes.
* Functional and unit tests are provided for all changes.
Part of blueprint service-hyper-uuid-in-api
Change-Id: I828350c179df8bcfa4739910abeafaba2f96982b
This patch introduces a new microversion to identify services by uuid
instead of id, to ensure uniqueness across cells. GET /os-services
returns uuid in the id field, and uuid must be provided to delete a
service with DELETE /os-services/{service_uuid}.
The old PUT /os-services/* APIs are now capped and replaced
with a new PUT /os-services/{service_uuid} which takes a uuid path
parameter to uniquely identify the service to update. It also restricts
updates to nova-compute services only, since disabling or forcing-down
a non-compute service like nova-scheduler doesn't make sense as it
doesn't do anything.
The new update() method in this microversion also avoids trying to
re-use the existing private action methods like _enable and _disable
since those are predicated on looking up the service by host/binary,
are confusing to follow for code flow, and just don't really make sense
with a pure PUT resource update method.
Part of blueprint service-hyper-uuid-in-api
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Change-Id: I45494a4df7ee4454edb3ef8e7c5817d8c4e9e5ad
This is the 4th patch of the series,
this patch adds a new microversion
in API to support adding tags when
booting instances.
Implemetes: blueprint support-tag-instance-when-boot
Change-Id: Ifcaaf285c8f98a1d0e8bbbc87b2f57fbce057346
In the resize API reference, mention that the specified flavor
must have a disk size greater than or equal to the current
instance flavor. This is something that doesn't get checked
in the API so it results in a failure on the compute service
which is not obvious to the API user since the instance goes
back into state 'ACTIVE'.
Change-Id: I33fc92ffa346b908a8e4f95da16a68040cfc678e
This patch marks the network related quota in the quota-class API
as deprecated in the 2.50 microversion. Also rewrite the release note for
2.50 microversion, change to describe the API change instead of the history.
Change-Id: Ida5518b7d43e85d9f30b11ed2819025a190aefd6
