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
Since 3.7.0, oslo policy started the DeprecationWarning[1] if
deprecated_reason and deprecated_since param are not passed
in DeprecatedRule or they are passed in RuleDefault object.
These warnings are logged for every test.
[1] https://github.com/openstack/oslo.policy/blob/3.7.0/oslo_policy/policy.py#L1538
Change-Id: I38c91afdfd773af96db9b2254281c383023481e4
Placement wants to always use the latest os-traits and
os-resource-classes libs. See
Idd4920885b10f0b21b2b67d9526f1048b06f7db5 .
The reason of the os-resource-classes major bump was dropping python 2
support:
$ git log 0.5.0..1.0.0 --oneline
3dd3506 (tag: 1.0.0) Switch to hacking 2.x
b99ab33 setup.cfg: Configure 'python-requires'
50b4160 Stop testing with py2
19b3411 Switch to Ussuri jobs
aaccfd9 Bump the openstackdocstheme extension to 1.20
fcd1be5 Merge "Build pdf docs"
432563f Merge "Update bug link in docs to point to storyboard"
718adcc Update the constraints url
65b74ff Build pdf docs
040e9c1 Update bug link in docs to point to storyboard
367698e Merge "Update api-ref link to canonical location"
d616e55 Update api-ref link to canonical location
8866073 Sync Sphinx requirement
4387894 Update api-ref location
Placement already dropped that so no extra measures needed.
Change-Id: I826ee41f7ef01c936d669024c6802091eb9c3bed
This change intoduces a set of jobs
that will run weekly in the periodic-weekly pipeline.
The intention of these jobs is to check the health
of the placement gate in the absence of frequent patch
submissions to ensure that new lib releases and or changes
in upper constraints or other placment related projects do
not result in broken jobs. The result of these jobs will
be review in our weekly meetings.
Change-Id: I456e44e69e503f2444ce9153aacee5783ea2b2eb
Placement does not use global CONF object. However when the policy
upgrade check was added in Ia7365cc3ae09e2ff916ab9f9ff0ba4fef0dc446b it
was referred to the global CONF object. However in placement it is not
initialized. Therefore the $ placement-status upgrade check fails with
oslo_config.cfg.NotInitializedError.
This patch makes sure that the policy upgrade check uses an initialized
config object instead.
Story: 2008831
Task: 42313
Change-Id: I7ef81df6ffa2eac96067b6c0370bd9792014e9cd
When running the functional tests locally:
tox -efunctional
the following error is raised from 6 tests in the
placement.tests.functional.db.test_migrations module:
RuntimeError: 'cryptography' package is required for sha256_password
or caching_sha2_password auth methods
This adds the 'cryptography' package to the list of required packages
for tests.
Story: 2008832
Task: 42317
Change-Id: I78fbdd723be089364b8ee61432eeb74ed6f24094
Add file to the reno documentation build to show release notes for
stable/wallaby.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/wallaby.
Sem-Ver: feature
Change-Id: I389984da2de958b4520ca3f26de48ef634d2c466
We attempt to parse the 'DBDuplicateEntry' exceptions raised by oslo.db
in the event of an integrity error to provide more useful information to
the user about what they did wrong. To do that, we're looking at the
'columns' attribute of this exception, which should list the conflicting
column(s), and extracting entries from the user-provided data based on
these columns names. However, on MySQL 8.x this does not return a column
name but rather a constraint name. This results in a KeyError when we
attempt to show the offending data by pulling it out by "column" name.
For example:
KeyError: 'resource_providers.uniq_resource_providers0name'
The solution is simple. Since there are only two unique constraints for
the 'ResourceProvider' model, we can simply check for these and map them
to their corresponding columns if found. The existing code can be
retained as a fallback for other database backends and legacy MySQL
versions.
Change-Id: I1dda02d46cb019eedd6e3ef64e327ac85bb7c484
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Story: 2008750
Task: 42110
In I0438e39a3c61253f781761a5aae895993f897adb,
I333147dcd47c6d0b926338a5a0c545f5adc63961 , and
Ia4d1871b719037174506fb784b77572e63303762 six new
traits were added, and a new os-traits was released
triggering the canary test for updating constraints.
Change-Id: I4fbab60f04f85d70c703385d7b43457045e3661d
All the policy rules are deprecated for base.RULE_ADMIN_API
so we can add this deprecation to base rule for system scope
which further can be used as new default for policies.
Change-Id: Idf028b44daab0469059d036c48d7c6ca36b01d96
Now that this feature is complete, we should document it. Do so with a
release note.
Change-Id: I69c4923463dea6f528d4fb98ac0d78b8b4cad12f
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This commit updates the policies for the resource classes in placement to
support read-only roles.
This is part of a broader community effort to support read-only roles
and implement secure, consistent default policies.
Change-Id: Ifeb5ae29d9d637708cd5c0bc62a2abfcbac3ca6e
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The 'HTTP_X_ROLES' header will include both the primary role of the user
and the implied roles. Clarify this in the stub we're using to mock that
out.
Change-Id: I0ab16c3a4d997a0a1f86d75323beaa86979bafa3
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
All of our granular rules have been transitioned across to the new
scoped policies, which means we can deprecate this base rule itself.
Change-Id: I2153099e5e6adc9fd276089194f5ec5bf4975420
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The 'placement' rule pre-dates the granular policies introduced in the
Rocky release, back when placement was still part of nova. It's no
longer used anywhere and can/should be removed.
This commit also updates a policy test to use a registered policy,
instead of the `placement` rule we're removing here. Otherwise, the
`authorize()` implementation will fail because the rule isn't officially
registered by placement.
Change-Id: I4b34c86a1991f954fc562b8e252fe9a178a08ad7
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This commit updates the policies for the usage resource in
placement to support read-only roles.
This is part of a broader community effort to support read-only roles
and implement secure, consistent default policies.
This commit also allows project readers to see project-specific usages,
resolve a long-standing policy TODO.
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
Change-Id: I80afaae965d3c5f862320ac11a7d05db2f6b6553
This commit updates the policies for traits in placement to support read-only
roles.
This is part of a broader community effort to support read-only roles
and implement secure, consistent default policies.
Change-Id: I5aec5f0ad24acd2c14c85a0a878c50790c2ab415
This commit updates the policies for the resource classes in placement to
support read-only roles.
This is part of a broader community effort to support read-only roles
and implement secure, consistent default policies.
Change-Id: Ie56fac6e0714f418b26c875735caf8867a1a1d9f
This commit updates the policies for the inventories resource in
placement to support read-only roles.
This is part of a broader community effort to support read-only roles
and implement secure, consistent default policies.
Co-Authored-By: Stephen Finucane <stephenfin@redhat.com>
Change-Id: I9add612f1533d0810cbfd0eadc358759e285ab6a
This commit updates the policies for the allocation candidates resource in
placement to support read-only roles.
This is part of a broader community effort to support read-only roles
and implement secure, consistent default policies.
Change-Id: I5197484395fd1f1e665e1882bd5884cba88ad40d
This commit updates the policies for the allocations resource in
placement to support read-only roles.
This is part of a broader community effort to support read-only roles
and implement secure, consistent default policies.
Change-Id: I1f47f1a96e32d3bc9526c14e5541af7992fd1f72
This commit updates the policies for the aggregates resource in
placement to support read-only roles.
This is part of a broader community effort to support read-only roles
and implement secure, consistent default policies.
Change-Id: I1242287418361ee48940f5bd2ee1bdc72cf1543e
This commit updates the policies for the resource providers in placement to
support read-only roles.
This is part of a broader community effort to support read-only roles
and implement secure, consistent default policies.
This commit also introduces some testing infrastructure and plumbing
that is useful for implementing protection tests with gabbi. Including
testing for deprecated policies.
Change-Id: Icc904bf325eaa60377171a22a86932135c384e6a
'oslo.policy' expects a list of default rules be provided when
initialising the enforcer. Unfortunately, it demonstrates a nasty habit
of modifying these defaults once it has them [1]. This can result in
configuration from one test bleeding through to the next.
Resolve this by initialising the enforcer with a copy of the default
rules, rather than the originals, allowing 'oslo.policy' to do whatever
it likes to the rules. Ultimately this should probably be fixed in
'oslo.policy', which should be either copying the defaults or creating
new rules based on these defaults, but that needs some thought and can
be done later.
[1] https://github.com/openstack/oslo.policy/blob/3.6.0/oslo_policy/policy.py#L762-L764
Change-Id: Ib864606d4cf4a8ecba95386bcc2b8a4bb68f2d17
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Story: 2008556
Task: 41687
These are making our logs rather horrific. Hide them.
Change-Id: I2853c7bd7c0afdeeed89ef412fc8830f04381d7b
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This oslo.policy Enforcer() object understands oslo.context
RequestContext objects and will translate the appropriate policy values
for you if it's passed into enforcement.
This lowers the bar for people interacting with oslo.policy because they
don't have to translate important authorization inforamtion from
RequestContext into a dictionary, specifically for policy enforcement.
Instead, they can just pass in the context object and oslo.policy will
know what to do.
This commit updates the policy module to do just that and moves the
credential tranlations to where it's needed, for logging.
Change-Id: I942da4b1880cf2312af2f8e15aef9f33be991f87
Balazs Gibizer
OpenStack Release Bot