These were deprecated during Stein [1] and can now be removed, lest they
cause hassle with the PCPU work. As noted in [1], the aggregate
equivalents of same are left untouched for now.
[1] https://review.opendev.org/#/c/596502/
Change-Id: I8a0d332877fbb9794700081e7954f2501b7e7c09
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The api documentation is now published on docs.openstack.org instead
of developer.openstack.org. Update all links that are changed to the
new location.
Note that Neutron publishes to api-ref/network, not networking anymore.
Note that redirects will be set up as well but let's point now to the
new location.
For details, see:
http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007828.html
Change-Id: Id2cf3aa252df6db46575b5988e4937ecfc6792bb
If more than one numbered request group is in the placement a_c query
then the group_policy is mandatory. Based on the PTG discussion [1]
'none' seems to be a good default policy from nova perspective. So this
patch makes sure that if the group_policy is not provided in the flavor
extra_spec and there are more than one numbered group in the request and
the flavor only provide one or zero groups (so groups are coming from
other sources like neutron ports) then the group_policy is defaulted to
'none'.
The reasoning behind this change: If more than one numbered request
group is coming from the flavor extra_spec then the creator of the
flavor is responsible to add a group_policy to the flavor. So in this
nova only warns but let the request fail in placement to force the
fixing of the flavor. However when numbered groups are coming from
other sources (like neutron ports) then the creator of the flavor
cannot know if additional group will be included so we don't want to
force the flavor creator but simply default the group_policy.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005807.html
Change-Id: I0681de217ed9f5d77dae0d9555632b8d160bb179
Since cells v2 was introduced, nova operators must run two commands to
migrate the database schemas of nova's databases - nova-manage api_db
sync and nova-manage db sync. It is necessary to run them in this order,
since the db sync may depend on schema changes made to the api database
in the api_db sync. Executing the db sync first may fail, for example
with the following seen in a Queens to Rocky upgrade:
nova-manage db sync
ERROR: Could not access cell0.
Has the nova_api database been created?
Has the nova_cell0 database been created?
Has "nova-manage api_db sync" been run?
Has "nova-manage cell_v2 map_cell0" been run?
Is [api_database]/connection set in nova.conf?
Is the cell0 database connection URL correct?
Error: (pymysql.err.InternalError) (1054, u"Unknown column
'cell_mappings.disabled' in 'field list'") [SQL: u'SELECT
cell_mappings.created_at AS cell_mappings_created_at,
cell_mappings.updated_at AS cell_mappings_updated_at,
cell_mappings.id AS cell_mappings_id, cell_mappings.uuid AS
cell_mappings_uuid, cell_mappings.name AS cell_mappings_name,
cell_mappings.transport_url AS cell_mappings_transport_url,
cell_mappings.database_connection AS
cell_mappings_database_connection, cell_mappings.disabled AS
cell_mappings_disabled \nFROM cell_mappings \nWHERE
cell_mappings.uuid = %(uuid_1)s \n LIMIT %(param_1)s'] [parameters:
{u'uuid_1': '00000000-0000-0000-0000-000000000000', u'param_1': 1}]
(Background on this error at: http://sqlalche.me/e/2j85)
Despite this error, the command actually exits zero, so deployment tools
are likely to continue with the upgrade, leading to issues down the
line.
This change modifies the command to exit 1 if the cell0 sync fails.
This change also clarifies this ordering in the upgrade and nova-manage
documentation, and adds information on exit codes for the command.
Change-Id: Iff2a23e09f2c5330b8fc0e9456860b65bd6ac149
Closes-Bug: #1832860
Turns out we've a *lot* of disparate metadata systems. Attempt to both
link them somewhat through extensive cross-referencing and extract out
deployment-specific stuff from user-facing docs. Lots of changes here,
but in summary:
- Split out admin-focused content from the metadata API, config drive,
user data and vendordata docs.
- Merge the config drive, metadata service, vendordata and user-data
user docs, which are mostly talking about the same thing and are
fairly barren without the deployment components
- Make use of various oslo.config and Sphinx roles
Side note: I miss when we have tech writers to do this stuff for us :(
Change-Id: I4fb2b628bd93358a752e2397ae353221758e2984
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This is a follow up to b129511050
which changes the code block in the docs to python and also
cleans up some of the NumInstancesFilter documentation, specifically
removing wording around "running" instances because the filter
does not care about state, only the number of instances reported
against a host - they could be stopped/paused/etc.
Change-Id: I7cdf79f21415fbf799fa5ad586f1b8063afed272
Since blueprint return-alternate-hosts in Queens, the scheduler
returns a primary selected host and some alternate hosts based
on the max_attempts config option. The only reschedules we have
are during server create and resize/cold migrate. The list of
alternative hosts are passed down from conductor through compute
and back to conductor on reschedule and if conductor gets a list
of alternate hosts on reschedule it will not call the scheduler
again. This means the RetryFilter is effectively useless now since
it shouldn't ever filter out hosts on the first schedule attempt
and because we're using alternates for reschedules, we shouldn't
go back to the scheduler on a reschedule. As a result this change
deprecates the RetryFilter and removes it from the default list
of enabled filters.
Change-Id: Ic0a03e89903bf925638fa26cca3dac7db710dca3
We're going to remove all the code, but first, remove the docs.
Part of blueprint remove-consoleauth
Change-Id: Ie96e18ea7762b93b4116b35d7ebcfcbe53c55527
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The RamFilter has deprecated since the stein release. We can show
another simple filter class here.
Change-Id: I15a935e80f6656c96c1e208746af1c89bf37b670
Replace 'is comprised of' with 'comprises'
because the 'is comprised of' is disputed use.
Change-Id: If66d2e4583b00102d52635457f3c3f8c2adee1be
Closes-Bug: #1831309
The description at the start of the docs is actually pre-pike
behavior replaced by the first "future plans" item which was
the counting quotas effort in pike. This change re-words the
main description to talk about counting quotas at a high level,
links in more of the relevant APIs, links to the config options
correctly, drops the future plan about counting quotas (since it
is no longer the future) and fleshes out a little blurb about
hierarchical quotas by linking to the unified limits spec.
Change-Id: I559938f69c9b462a9b0baeb5d1d4d915f893273e
This removes the old reference to the nova-manage
command to refresh quota usage which no longer
applies since we started counting quotas in the
Pike release.
This replaces with a reference to the down-cell
known issue for counting quotas.
Change-Id: I2765f3ca3dc95345d4e4c4db43ac3dff4a509259
The flavors section of the user guide is comprehensive with many
sub-sections, but only some of them had anchor ids. Add anchors for
the rest so that deep-linking to any of these sub-sections is
possible.
Change-Id: I84984d7534c9c92b51fb4e1797cf6a9db3c28755
Since the [cinder]/cross_az_attach configuration is all
about availability zones matching between servers and volumes,
we should mention it in the AZ documentation.
Change-Id: I7055104d0b9dbd7efdef6d02c18541172059724f
There was nothing clearly documented about move operations with
respect to AZ restrictions, i.e. when a server can move between
zones or not, and how forcing a target host during evacuate or
live migration can break tracking of the instance for it's orginally
intended zone. This adds documentation around that topic.
Change-Id: I7466826780ea8a6b3d3df93f0e85f009a437b743
Closes-Bug: #1823043
This patch adds a table of possible extra-spec/cpu_shared_set
combinations, and lists the expected behavior of instance emulator
threads for each case. This is an improvement over the previous doc,
which incorrectly implied that `share` was the default policy value,
and only covered what happens if cpu_shared_set is set.
Change-Id: Ia56607d0b70d5f46159b57ee1092ba0e37a02270
This document was written back in the liberty release [1]
and says that conductor is not used for orchestrating the
resize/migrate flow, but given the description of how
conductor is used to orchestrate scheduling and reschedules
during a server create, it is unclear why the doc says that
resize is not used the same way since it is used for rescheduling
when prep_resize fails in a selected dest compute. This removes
the caveat to reflect reality.
[1] Ieb9134302d21a11fe9b9ee876bb7b0dd32b437e1
Change-Id: I932a7ac6870a3f9d26556c23c9074115963b3c27
Add descriptions about numbered resource classes and traits
in the Flavor doc.
Change-Id: I4878df606037ca95441bdefd748f4fc9eabedf97
Closes-Bug: #1800661
The admin and user flavor docs on pci.alias were not super
helpful by just throwing the user to the config docs or
flavor docs and letting them figure it out. This change
helps the reader by linking directly to the things being
referenced.
Also cleans up a pci.passthrough config option reference
while in here.
Change-Id: Ie2e28a14ff4655e38a5db3925adcd605ac773843
Remove wrong description for auto resize confirm
in the API guide.
Move a description of a configuration option
'resize_confirm_window' from the API guide
to the admin configuration guide.
Add a description of automatic resize confirm
in the user guide.
Change-Id: If739877422d5743e221c57be53ed877475db0647
Closes-Bug: #1816859
The "availability_zone" parameter for server create in the
API reference and the availabilty zone user docs both say
that users should not use the default availability zone (nova)
yet our server create API samples use "nova" which is...bad.
This change fixes the API samples and related tests to use
a fake "us-west" availability zone. For any samples that were
requesting an AZ when creating a server, those are changed from
requesting "nova" to requesting "us-west" and a new
AvailabilityZoneFixture is added to stub out the code used to
validate the requested AZ and what is shown in server detail
responses.
Some unused samples are removed from the os-availability-zone
directory and the API reference and AZ user docs are updated for
formatting and linking to other docs for reference.
Change-Id: I3161157f15f05a3ffaaf1b48e7beb6b3e59c5513
Closes-Bug: #1817963
Adds a section in the admin guide with the config options related to
down cells.
Related to blueprint handling-down-cell
Change-Id: I6a6cc71e83896aaccd5dd98bc2ea024d6f22d528
This patch adds the documentation around the work regarding
handling down cells that was introduced in v2.69.
Related to blueprint handling-down-cell
Change-Id: I78ed924a802307a992ff90e61ae7ff07c2cc39d1
As discussed in the mailing list [1] since cells v1
has been deprecated since Pike and the biggest user
of it (CERN as far as we know) moved to cells v2
in Queens, we can start rolling back the cells v1
specific documentation to avoid confusing people
new to nova about what cells is and making them
understand there was an optional v1.
There are still a few mentions of cells v1 left in
here for things like adding a new cell which need
to be re-written and for that I've left a todo.
Users can still get at cells v1 specific docs from
published stable branches and/or rebuilding the
docs from before this change.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002569.html
Change-Id: Idaa04a88b6883254cad9a8c6665e1c63a67e88d3
Zuul