This is the code used to run placement with the wsgi
profiling described in a blog post [1]. It has proven
useful enough that we may wish to include it in the
released code. It is added in a way that is off by
default and makes no changes to requirements.
Brief docs are included in testing.rst. They are
brief because it's assumed that someone who wants to
do this already mostly knows what they want to do and
merely needs the specifics on how to do it in this
environment.
[1] https://anticdent.org/profiling-wsgi-apps.html
Change-Id: I342512732b94bc19bd711684ba3ec9480cc51f81
To support QoS minimum bandwidth policy during server scheduling
Neutron needs to know which resource provider provides the bandwidth
resource for each port in the server create request.
Story: 2005575
Task: 30804
Change-Id: Iafdb0eab9b41f4c34c93cada08a4da27cf4b1499
We want to drop the REST API compability code for resource
providers with no root_provider_id in Train, so to start
we should make the related upgrade check a failure rather
than a warning.
Change-Id: Ifd3c84ea3348fc9e6653838d6fba4a5eb864f01e
Story: 2005613
Task: 30921
Add a 1.33 microversion to move from numeric suffixes to string
suffixes that can be 64 chars longs made from '-', '_', and
mixed-case alphanumeric. The format is shared between schema
and RequestGroup parsing.
Docs, api-ref, api history and microversion upper limit are updated
to indicate the new form in the new microversion.
A release note is added.
Story: 2005575
Task: 30781
Change-Id: Ia44b0922d151695d406883262e891bd932536f38
Since some people may be looking for docs-related work,
add a link to the docs worklist. Stories in the placement
project group show up there if they have been tagged 'docs'.
Change-Id: Ie9ff8c3527c145b4cbc356444acc587931398d00
Having the db migration scripts within the openstack-placement pypi
distribution is desirable for deployment tools, such as
openstack-ansible. It provides a known good location for the script,
available with a pip install.
There are several ways to distribute files with a python package. The
method used here was chosen because it works both with tarballs and
wheels (the files are already in the tarball, as a result of the way pbr
works, but not in the wheel).
Here's what's done:
* The db migrate scripts are put in their own direcory,
placement_db_tools, so that only they are packaged, not the other
tools.
* To preserve how grenade interacts with these files as well as not
disrupt the docs, symlinks from tools to placement_db_tools have been
created.
* placement_db_tools is added to the list of packages included in the
openstack-placement distro. This means that when 'pip install
openstack-placement' happens, the python environment will then include
placement and placement_db_tools directories.
The end result is that the true path to the script can be found with:
pkg_resources.resource_filename('placement_db_tools', 'mysql-migrate-db.sh')
This has been noted in the to-stein.rst document.
A different package was chosen to not muddy the waters of what is
"actually placement".
Similarly, the 'data_files' functionality provided by pbr was not used,
because that requires the file be written to a location on the local
filesystem, relative to the install prefix. Dirtying the filesystem
outside the python lib with this sort of thing is inappropriate.
Change-Id: Ie326ce8a2a0692d20793bc18be606e034fa94a44
Story: 2005535
Task: 30671
When the worklists were first created, cdent was unaware of
how to make the worklists filter by story state so a tag of
'fixed' was being used to indicate "done".
This change updates the docs to reflect new awareness. The
associated worklists have already been updated.
Change-Id: I445b67ff85be7979805d72ac953f0853ee738f46
The "Upgrading from Nova to Placement" doc mentions the
postgresql-migrate-db.sh script but within a big wall of
text and the rest of the examples in the guide are using
mysql, so people might miss the postgresql script which
could result in errors later if their sequence ids are
wrong.
This adds a note to serve as a reminder.
Change-Id: Id93531cc2d440b1adde1c0bd7c504f737b14012c
Story: #2005478
Task: #30568
These worklists exist but are not easily discoverable so
they need to be linked from somewhere. contributing.rst seemed
like the best place.
Change-Id: If74cf2f510441f500c2e13612f99631d56cf4bfe
Review of changes to contributing.rst noticed an unrelated
typo in the arguments used in the examples for visual indent.
Change-Id: I2268fa6aa6c9272ffbb7b6d3b439539765197fed
"Progress" is the wrong state for a task that has been
submitted for review. The correct state is "Review".
Update contributing.rst to reflect this.
Change-Id: I221fc533ba86e82dc6f119ef20fc25a54a162f92
Provide several rules and guidelines for constructing good
changes to submit to gerrit. This list can never be complete
but this gets us started. As with everything else, there's a
balance between being too prescriptive and not prescriptive
enough.
Change-Id: I30243e81ea8711296ce0884d93e985c6d2b5cefd
Write up general outlines on managing specs. As with the other
section, this avoids overloading the description with too many
details. As we discover gaps we can fill them in.
Change-Id: I2d980ea05be5067cd2c98919854cedeb438f6893
This provides some links to more info about reviewing, and some
guidelines on how to be a good reviewer, with special
considerations for cores.
Not included is information on how a patch submitter should hassle
someone to get attention. With the low volume of patches that go
through placement, that should not be something the submitter should
have to care about. It's the job of regular reviewers to be aware
of new stuff. The guideline about latency covers that.
Change-Id: I61cf791c956a75304b87ffb4a16a8252fc36800b
For now just the very basics of how to create a good bug, what tags
to use, information to include, etc. And some encouraging words on
doing triage.
At this time no effort is made to describe a process for things like
"backport potential" or what release something is associated with.
We'll figure out that once, as a group, we have a better idea of what
StoryBoard can do for us. It is likely that a combination of tags
and tasks will be the order of the day.
Change-Id: Ie9e3a2c624357c846bf861ae6de39396a0fd958d
We have contributor documentation, that explains placement
from within, but we don't have much in the way of docs that
explain how to make contributions and the guidelines for
how do it well. This patch is the first in a series that will
add that information.
This first patch simply creates an initial contributing page
with a light intro and titles for four initial sections.
Change-Id: Iea127a052a42ed5cc5349b89137381f782717af3
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
We decided in IRC and email discussions that henceforth
placement specs will reside in the same tree as code and docs.
This change sets that up using the following structure:
* There is a docs/source/specs top-level index that should be
updated with each release to include tables of contents generated
from cycle directories (currently pointing to train) for
approved and implemented specs.
* In the approved directory for any cycle there will be a
<cycle-template>.rst file to use as the basis for any new
spec. New specs go in this directory.
* In the implemented directory is a placeholder file which
will be removed when the first (if any) spec moves from
approved (meaning in-progress) to implemented. The PTL
or their designee will be responsible for doing that moving.
The placeholder file is required to avoid warnings (which
will kill the tox docs job) from the table of contents
globbing.
* The train-template.rst is a copy-with-edits from nova's
version of the same thing. The main changes are to indicate
that StoryBoard, not launchpad blueprints, are the starting
point and to remove various nova-isms.
It is likely we will want to further tweak the template as
we decide what matters.
The next steps for this are for people with placement specs
that had been pending in nova in stein, to resubmit them to
placement as train specs (in doc/source/specs/train/approved).
It is quite likely and not surprising that it will sometimes
be confusing whether a spec should be in nova or placement.
Ideally we can identify the "just placement" aspects of a
change and make a placement-only spec for that which the nova
spec makes reference to. This may sound like a pain but it is
a feature, not a bug, which helps make sure that placement
evolves its API as a strong contract for all potential clients.
Change-Id: I85854d771409701cea2fcf7a218f02af60dba72e
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