Mistakenly the computing team merged two specs in nova that actually
targeting the placement service. Placement has its own specs directory
to store these. So this patch adds the these specs to the placement
repository.
The only change in the two specifications compared the ones approved in
nova-specs repository is the removal of the note from the top that they
are targeting placement service as it is now obvious.
Change-Id: Ie0d4df94ae16de60394438878e5a1568e29e03a5
In the top index page of the document, some sections had actual
contents and some had only links to the contents. However, this
makes it difficult for readers to get what is in the document and
what isn't at a glance.
This patch cleans it up to simplify the top index. This patch also
renames some of the directories to follow the doc layout rules[1].
[1] https://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html
Note that the following ToDo is left for further cleanup:
* Publish the api guide and move the microversion history to
the `/api-guide` directory
Change-Id: Ideb1d5e7c74d1d564d07bac1a1e7c86c55ede873
root_member_of was not implemented (as we thought it might not be).
The spec is updated to make this explicit.
Change-Id: I2a60bff04b0837bcac7037d766c675ef3896692f
Forbidden aggregates was added in microversion 1.32 (part of Train)
and allocation candidates mappings was added in 1.34 so those specs
have been moved to implemented.
An _extra/.htaccess is added to redirect the approved spec to the
implemented spec. If we're experiencing enough volume of specs to
warrant automating this, it should be easy to do, but at this point
we don't have, nor intend to have, large numbers of specs.
While doing that I noticed the management of spec documents can be
simplified somewhat by moving placeholders and templates to a
non-release specific location. The placeholder can then be used
as a symlink when in approved or implemented when those are first
created or otherwise empty (an empty directory when doing a table of
contents glob is an error so some kind of file is needed).
Contribution docs are updated to reflect the location of the
template.rst file. The template.rst file is updated to be release
generic.
Change-Id: Icb886d5062a52bfc757ed7bbe36ed8a63abe1387
This spec aims at providing support for services to model
``consumer types`` in placement. While placement defines a
consumer to be an entity consuming resources from a provider
it does not provide a way to identify similar "types" of
consumers and henceforth allow services to group/query them
based on their types. This spec proposes to associate each
consumer to a particular type defined by the service owning
the consumer.
Change-Id: I79ce8f1b20c60b89fc1ed0ece8bcc321e9435bad
Story: 2005473
Task: 30554
This is a spec for several nested features which has been split
off from the original spec for nested magic [1] in an effort to
not delay progress on these features while 'can_split' is being
discussed.
This spec describes a cluster of Placement API work to support several
interrelated use cases for Train around:
* Modeling complex trees such as NUMA layouts, multiple devices,
networks.
* Requesting affinity (in the NUMA sense) between/among the various
providers/allocations in allocation candidates against such layouts.
* Describing granular groups more richly to facilitate the above.
* Requesting candidates based on traits/aggregates that are not
necessarily associated with resources.
In particular, it describes the new GET /allocation_candidates
features:
* arbitrary group suffixes
* same_subtree query parameter
* resourceless request groups
* root_required, root_member_of
[1] I7c00b06e85879ab1bf877ce32979e8cc898bfd9e
Co-Authored-By: Eric Fried <openstack@fried.cc>
Change-Id: I55973aa7de4a85b63dff4a7d1afb6c36796af71a
Story: #2005575
Task: #30949
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
This series reproposes the forbidden aggregates spec to placement train
directory copying it from nova stein directory. Two changes were made.
1. Procedural change.
- The reference URL is changed from launchpad to storyboard.
- The history section is added.
- The file is renamed to have the prefix of the story id
2. Essential change
- The behavior of the API when an agg UUID is found on both the
positive and negative sides of the request is documented in
the 'REST API impact' section.
This patch contains the essential change.
Change-Id: Ie67560dbd61ecdc0ad2fe98e9ca9df554edbb1de
Story: 2005297
Task: 30183
This series reproposes the forbidden aggregates spec to placement train
directory copying it from nova stein directory. Two changes are made.
1. Procedural change.
- The reference URL is changed from launchpad to storyboard.
- The history section is added.
- The file is renamed to have the prefix of the story id
2. Essential change
- The behavior of the API when an agg UUID is found on both the
positive and negative sides of the request is documented in
the 'REST API impact' section.
This patch contains the procedural change. The essential change will
be done in a follow up.
Change-Id: Ie56739f8979cb4dd318d2bdb9cb6eb9fa447328d
Story: 2005297
Task: 30183
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
Balazs Gibizer