v0.4.0 Release Notes¶
0.4.0 Release Notes¶
0.4.0¶
Prelude¶
This release is to tag the Patrole for OpenStack Rocky release. After this release, Patrole will support below OpenStack Releases:
Rocky
Queens
Pike
Current development of Patrole is for OpenStack Stein development cycle. Every Patrole commit is also tested against master during the Stein cycle. However, this does not necessarily mean that using Patrole as of this tag will work against a Stein (or future release) cloud.
New Features¶
In order to strive toward complete test coverage for the services it tests, Patrole now offers RBAC coverage for the APIs included in neutron-tempest-plugin. If this plugin is not installed or enabled, then Patrole will skip those tests.
A new configuration group
[policy_feature_enabled]
has been added to Patrole which will be responsible for collecting the feature flags to be used for newly introduced policies or policies that were changed in a backwards-incompatible way.create_port_fixed_ips_ip_address_policy (Neutron)
update_port_fixed_ips_ip_address_policy (Neutron)
limits_extension_used_limits_policy (Cinder)
volume_extension_volume_actions_attach_policy (Cinder)
volume_extension_volume_actions_reserve_policy (Cinder)
volume_extension_volume_actions_unreserve_policy (Cinder)
These feature flags will be supported until Pike release cycle is EOL.
Patrole now offers support for multiple policies. The
rules
argument has been added to therbac_rule_validation.action
decorator, which takes a list of policy names which Patrole will use to determine the expected test result. This allows Patrole to more accurately determine whether RBAC is configured correctly, since some API endpoints enforce multiple policies.Multiple policy support includes the capability to specify multiple expected error codes, as some components may return different error codes for different roles due to checking multiple policy rules. The
expected_error_codes
argument has been added to therbac_rule_validation.action
decorator, which is a list of error codes expected when the corresponding rule in therules
list is disallowed to perform the API action. For this reason, the error codes in theexpected_error_codes
list must appear in the same order as their corresponding rules in therules
list. For example:expected_error_codes[0] is the error code for the rules[0] rule. expected_error_codes[1] is the error code for the rules[1] rule. …
Upgrade Notes¶
The
admin_only
kwarg has been removed fromrbac_rule_validation
decorator because it is no longer used by any tests. Besides that, it should not be used because Patrole is dedicated to RBAC testing and an admin-only check is not RBAC because it does not useoslo.policy
library.
The
switch_role
method inrbac_utils
module has been removed because it is a clunky way of manipulating Tempest roles to achieve RBAC testing. Useoverride_role
instead.
The
[patrole].strict_policy_check
was deprecated during the Queens release cycle. It is removed in this release cycle because Patrole should always fail on invalid policies.
Deprecation Notes¶
The
[patrole].enable_rbac
option is deprecated and will be removed during the “S” release. This is a legacy option that was meaningful downstream when Patrole was a suite of tests inside Tempest itself. Now that Patrole exists upstream as a Tempest plugin, it is paradoxical to install the Patrole plugin yet have an option that allows all Patrole tests to be skipped. This option is at odds with current Patrole architecture.To skip RBAC tests going forward, with Patrole Tempest plugin already installed, use an appropriate regex.
The
rule
argument in therbac_rule_validation.action
decorator has been deprecated in favor ofrules
.The
expected_error_code
argument in therbac_rule_validation.action
decorator has been deprecated in favor ofexpected_error_codes
.