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
This fixes a formatting issue in the member_of 1.21 parameter
to the GET /allocation_candidates API reference.
Change-Id: I53289e98d76c22b220066b22de7f21552dc5378a
Review of changes to contributing.rst noticed an unrelated
typo in the arguments used in the examples for visual indent.
Change-Id: I2268fa6aa6c9272ffbb7b6d3b439539765197fed
Far as I can tell, this has no users outside of a unit test and can
therefore be removed.
Change-Id: I844959d2a6cf956cb59a78fddbec5301fb9fdc4b
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
"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
Now in API reference, variable name `member_of` is used for
`GET /resource_providers` doc and `member_of_1_12` is used for
`GET /allocation_candidate` doc. However, since we also have
`member_of_granular` this can be confusing.
This patch renames as follows:
- `member_of` -> `resource_providers_member_of`
- `member_of_1_12` -> `allocation_candidates_member_of`
- `member_of_granular` -> `allocation_candidates_member_of_granular`
No content is changed.
Change-Id: I3a8591d9ed76eed60e11d59cff77cfbf95796478
This is a follow up patch on negative-aggregate-membership series.
- Remove allocation candidate related words in the
`GET /resource_providers` API reference
- Fix several typos in the API reference
- Additionaly write in the release note that the forbidden aggregate
is also supported in granular requests.
Change-Id: Idb187d7ef83ad65aaaa5dbf968a15c41d73057d1
This patch refactors _get_trees_matching_all() not to
return orphaned resource provider due to aggregate filter.
Change-Id: I4d23ecdca67ca0864b24e25902df53c64e7329a7
Some tests in ResourceProviderListTestCase validated the number of
resource providers returned by p_obj.get_all_by_filters(), but didn't
validate if they are proper resource providers.
This patch adds that check adding a small test helper function,
_run_get_all_by_filters().
Change-Id: Id642d89c854744cbc2d36519004c87e9f2546269
This patch adds microversion 1.32 supporting the forbidden aggregate
expression within existing ``member_of`` queryparam both in
``GET /resource_providers`` and in ``GET /allocation_candidates``.
Forbidden aggregates are prefixed with a ``!``.
We do NOT support ``!`` within the ``in:`` list:
?member_of=in:<agg1>,<agg2>,!<agg3>
but we support ``!in:`` prefix:
?member_of=!in:<agg1>,<agg2>,<agg3>
which is equivalent to:
?member_of=!<agg1>&member_of=!<agg2>&member_of=!<agg3>
where candidate resource providers must not be in agg1, agg2, or agg3.
Change-Id: Ibba7981744c71ab5d4d0ee5d5a40709c6a5c6b5e
Story: 2005297
Task: 30183
This patch prepares for supporting negative member_of queryparam
in DB layer changing the following function:
get_trees_matching_all():
- used in GET /allocation_candidates for the case where the
granular request is not specified and sharing provider or
nested provider exists.
Change-Id: Iafa51cca86eb5a4b480c8296e2ee059ae2b69948
Story: 2005297
Task: 30183
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
Nothing is being translated in placement so, for the sake of being clean
and tidy, this patch removes the framework for translation and the
import of oslo.i18n.
Originally the hope was we could remove the dependency on oslo.i18n and
Babel entirely to save some disk space but many other oslo-related libs
depend on oslo.i18n so they are present anyway. [1]
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004220.html
Change-Id: Ia965d028b6f7c9f04d1f29beb12f4862585631d5
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