This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.
This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.
This update should result in no functional change.
For more information see the thread at
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003825.html
Change-Id: I669e77c1cc1d626552939b8f65e093e7901ad754
This adds content to the verify doc, part of which is
the placement-status upgrade check command usage from
the from-pypi doc.
Change-Id: I06e731314e8aad8e314e2ba2c3765c19a6c32bf5
Story: 2005190
Task: 29944
In the review of the initial create of the `to-stein` document [1]
some shortcomings were identified that this patch tried to address:
* making it clear that upgrading to extracted placement doesn't have to
be the same time as upgrading to stein
* stop using contractions
* clarify several points. In some cases this means being more
general, in others more specific
* Add some thoughts on verification
* Change the verb "copy" to "move" in a few places. This was done
to help make sure that nova will not remain configured to use
its own placement, which would be very messy.
[1] I32b22d75400c7f7b428ed3d48ac928584071ed29
Change-Id: I722275eba2d17e0751a9a4ccfc58a8e7ede864da
The deployment section provides an overview of install steps.
Make it a bit more useful by linking to examples of creating
service user and service catalog entries.
Change-Id: I3661cdea9e182a87821ac3d18ca0e2fe045947f1
Story: 2005190
Task: 29938
This is an attempt at documentation for upgrading to extracted placement
from nova. It is effectively a translation, with links, of the script
used in grenade. It tries to provide details where it matters, but be
vague where independent initiative is warranted.
Story: 2005190
Task: 29940
Change-Id: I32b22d75400c7f7b428ed3d48ac928584071ed29
Provide step by step instructions for installing from pypi.
Note that this is a greenfield installation, not an upgrade.
Only one of many possible web servers is described as there
are too many choices to describe them all.
The depends-on adds oslo.log to config doc generation,
allowing a link to the debug option. This is done as a
depends-on to avoid a rebase.
Depends-On: https://review.openstack.org/644589
Change-Id: I580fa4394cb93b8e8141ee2d546543c174356a47
Story: 2005190
Task: 29943
The concept/name of controller was copied over from nova when the
docs were imported. That concept doesn't really fit in with
placement and also does not describe what the docs are actually
doing. We're not installing a controller, we're installing
placement.
Thus filenames and titles are updated and intro paragraphs
clarified.
Also, the endpoints.rst file is moved into a shared directory as it
is not a standalone install doc.
Note that the big warning remains on the top of the install docs
because it is still true. These instructions and the packages they
mention have not been verified.
Story: 2005190
Change-Id: I5fcbc90eda3ef74dba2336ea3e5c9f53938c6378
There wasn't really a good overview on how to use placement,
so I've tried to start something by expanding on how nova uses
placement in very broad strokes. The intent here is not to
instruct people on the details of how to manage resources with
placement, rather that they _can_ manage resources with
placement and here's the major steps involved.
Change-Id: I11cd622162efce2e87a21fa5ae5d297f4b248541
When the install docs were ported from nova, cleaning up "databases" ->
"database" was inconsistent. This patch gets the lingering errors.
Change-Id: Id051d8656c58dfc0a351a6de540bb12ef69c1bc6
We got rid of OVO and otherwise refactored the object layer,
so make that (more) clear in the contributor docs.
Change-Id: I9995a81e47daa4d151d3ff1f027e8caf474a69ed
Story: 2005190
Task: 29945
The placement user and service catalog endpoint creation information
in the three different distro docs is very nearly exactly the same
so it has been extracted to a file which is included by all three.
This file can then be reused elsewhere as well, such as planned
"from-pypi" install docs (for which there exists a stub).
The only difference in the three versions was the URL used for
the endpoint(s) which already required some cooking to work in
any environment. A note has been added to point out the installar's
responsibilities in this case.
Subsubheadings are introduced in the surrounding document so that
the numbered list is considered two separate lists. Otherwise the
output ends up looking like a single list with two initial number
one items.
Change-Id: Ib928162702a54f000161367c90172c730cb632c7
* remove the reference to gabbi, as that seems out of date now
that the api-ref is so huge
* add discussion of "any client that works"
* add links to openstackclient and osc-placement
Story: 2005190
Task: 29941
Change-Id: I257c4dbcec9ed68e3562d6001174bff0d679609e
* Link directly to the scripts in git.o.o
* Changes the information about needing the migration to a warning,
for sake of visibility
* Note that an upgrade at the same time as everything else is not
required
These changes aren't intended as a substitute for true "upgrading from
nova docs", rather that in this particular place in the docs, something
needs to be said to summarize. Later changes that write that true
doc will be linked to from here.
Story: 2005190
Task: 29939
Change-Id: Iae418d8bf385134ff1a93c6251bd9bf0eeee7b3e
Clarify the options for database synchronization and clean up
how the relevant oslo.config options are linked.
Story: 2005190
Task: 29937
Change-Id: I3128203eed4ac9d0b5aa568993390212c62ffeeb
Update doc, api-ref and releasenotes conf.py to set 'use_storyboard' to
True. According to the docs of the theme [1] bug project and tag are
not used when using StoryBoard.
doc/requirements.txt (used by all the docs-related jobs) is updated
to make openstackdocstheme>=1.24.0. That version is the most recent
one to have bug fixes related to use_storyboard.
[1] https://docs.openstack.org/openstackdocstheme/latest/#using-the-theme
Change-Id: I3b28dd1da9e8e75eda151a3025e78a5a47c971f9
Story: 2005190
Task: 29948
In preparation for extending the testing documentation to include
information about more than just gabbi, including the tempest,
grenade and perload jobs, pull the content out to its own page.
As noted in a TODO within, making subpages show up is cumbersome
for the moment, but we can iterate to something swell.
Change-Id: I71d000804985aaf5f3a1c467974ac7f8d0250a98
https://review.openstack.org/#/c/632599/ added a new check for missing
root provider ids, but missed to update the placement-status-checks
history in the doc, so this patch updates it.
Change-Id: I8f5dc7b25ded628772d3863e4ccecb14b5224c58
Since the create_incomplete_consumers online data migration
was copied from nova to placement, and will eventually be
removed from nova (and the nova online data migration won't
help once the placement data is copied over to extracted placement
on upgrade anyway), this adds an upgrade check to make sure
operators completed that online data migration.
Normally we wouldn't add upgrade checks for online data migrations
which should get automatically run by deployment tools, but since
extracted placement is very new, it's nice to provide tooling to
let operators know they have not only properly migrated their
data to extracted placement but whether or not their upgrade
homework is done.
Change-Id: I7f3ba20153a4c1dc8f5b209024edb882fcb726ef
When nested resource provider feature was added in Rocky,
root_provider_id column, which should be non-None value, is created in
the resource provider DB.
However, online data migration is only done implicitly via listing or
showing resource providers. With this patch, executing the cli command
`placement-manage db online_data_migrations`
makes sure all the resource providers are ready for nested provider
feature, that is, all the root_provider_ids in the DB have non-None
value.
Change-Id: I42a1afa69f379b095417f5eb106fe52ebff15017
Related-Bug:#1803925
Placement uses alembic to manage the DB version for schema changes.
However, changes with data manupulation should be separated from the
schema changes since the table can be locked and in the worst case
it breaks the service for backward incompatible changes.
We could handle them as a task that is done in a service down time.
However, to minimize the down time, it is better to have the concepts
of online data migration which has been a traditional way to handle
those data manipulation changes in nova.
This patch adds online data migration command to placement to enable
operators to manipulate DB data while the service is running:
placement-manage db online_data_migrations [--max-count]
where --max-count controls the maximum number of objects to migrate
in a given call. If not specified, migration will occur in batches
of 50 until fully complete.
Change-Id: I9cef6829513d9a54d110426baf6bcc312554e3e7
This is a first pass at creating the install documentation for
placement, by copying the nova install documentation, and removing the
nova parts, leaving the placement parts in place.
The expectation here is that this provides a starting point which
can be iteratively improved, perfection being the enemy of the
done and all that.
The from-pypi and verify pages are currently left as TODO and not
included in the visible table of contents. They are present in
the hidden table of contents.
Change-Id: I2f7bcd8efabc628bd27e3a9ce74e277a9e37fb69
Add a section to the api-ref describing the error codes that some
responses produce.
Note in the contributor docs that this should be updated when one is
added.
The reshaper docs is adjusted so a ref can be made to it from the
errors. The implicit link to the header that would be the norm there
doesn't work as there are two headers named "Reshaper".
Change-Id: I89bbd383ba102fdd707ccc9f2fc973c6dd841fa8
Closes-Bug: #1794712
Now we have `placement-manage db sync` CLI, which upgrades the
placement DB to the current version using alembic. However, if you
have already created tables in placement, the command fails on having
the initial upgrade: (initial) -> (b4ed3a175331). This is because it
assumes the initial DB has no contents and tries to create the tables.
Since this can be a problem for nova-api -> placement migration case,
where we expect placement DB has tables before starting alembic
version mangement via the migration script in `tools/*-migrate-db.sh`,
this patch provides a way to stamp the current version via the CLI:
`placement-manage db stamp <version>`.
Change-Id: I65fa8fd6e2479224f1b25cd62ca15a90d5948424
When I initially wrote the goal, I figured it would be ages before we'd
do it, but the difficulties with the functional tests changes in nova[1]
meant we did it sooner than expected.
[1] Idaed39629095f86d24a54334c699a26c218c6593
Change-Id: Ia48431503ce19feb0ac7a16cc65f699c58a57af2
As explained in the document, this is a way to keep track of long term
ideas or hopes that are too far away or too vague to warrant specs, even
wishlist specs. The main goal of these goals is to keep an eye forward
to long term improvements which are not really related to features, but
instead are directed towards making contribution and maintenance more
pleasant.
Change-Id: Ic76852d3bea36f797dd845fd7be520670d214aa3
Discussion in IRC suggested that
https://anticdent.org/quick-placement-development.html ought to do in
the contributor docs, so here is a version of it, translated from
Markdown to RST.
Change-Id: I7a014e96d2f4c01594d977c5a4af9894278dd511
This is the first in a series of changes to the content in
doc/source to make it more accurately reflect the current state of
placement, now that it is in its own repo.
There are small changes throughout the front page, mostly to make
it more clear and make useful stuff a bit more discoverable.
The two major changes are:
* Older (pre-stein) upgrade notes are found by linking back to
nova's rocky documentation.
* The REST API history is moved to its own sub-page, otherwise it
the page is overwhelming and noisy.
Close review is probably required. cdent typed this. That has
implications.
Change-Id: I66e0c7d18b253b0a5a8fdac65e30b5b3cef37db2
The default bug tag for placement doc is defined
as 'docs' currently in doc/source/conf.py.
But it should be 'doc'(*1) instead of 'docs'.
So replace 'docs' with 'doc'.
*1: https://wiki.openstack.org/wiki/Nova/BugTriage#Tag_Owner_List
TrivialFix
Change-Id: I469ad687f655b96f7a0be11e1b92e30a31e3184d
This adds the basic framework for the
placement-status upgrade check command which
is a community-wide goal for the Stein release.
A simple placeholder check is added which should
be replaced later when we have a real upgrade
check.
Change-Id: I9291386fe7fcbfc035c104ea9fdbe5eb875c4776
Story: 2003657
Task: 27518
This change adds a rudimentary command line tool, 'placement-manage'
that can do three things:
* placement-manage --version: report the current version of the software
* placement-manage db sync: sync the db to the 'head' alembic version
* placement-manage db version: report the current version of the db
It is written following the examples set by both nova and ironic for
using oslo config driven command line parsing. It is not as full
featured as the nova version (with decorators for argument handling and
help text etc) because we don't need that yet. There's plenty of room
for improvement, but the intention here is to keep things simple until
we need them to be otherwise.
The provided unit tests cover that the arg parsing behaves as expected
and that the right commands are connected the right args. The actual
functionality of the 'db sync' command (a migration.upgrade) is tested
in runs that use devstack as well as the test_migrations functional
test.
Errors during the migration simply raise exceptions which will output
noisily to the console. At this stage this is desirable and suitable.
A new doc for the cli is added, with basic information for
placement-manage. Note that at this time the deployment documentation
has not been updated. That will be done in a later change.
Future changes may include (if we can't avoid it) tools for initiating
online migrations from the command line.
Needed-By: https://review.openstack.org/600162/
Change-Id: I1ff472106610150a587f5286f26a6bd7c1aa84f4
This gives some basic documentation for creating a revision using
alembic. It then links to the alembic tutorial for more information.
Change-Id: I8647aaa55dca537d95c7c03753f2a24f364f0ddf