summaryrefslogtreecommitdiff
path: root/releasenotes
Commit message (Collapse)AuthorAgeFilesLines
* Update master for stable/2023.1OpenStack Release Bot2023-02-242-0/+7
| | | | | | | | | | | | Add file to the reno documentation build to show release notes for stable/2023.1. Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/2023.1. Sem-Ver: feature Change-Id: I279a3b56f331ad2dcafd624f0d8ea166713a58c5
* Imported Translations from Zanata4.1.0OpenStack Proposal Bot2022-10-171-7/+1
| | | | | | | For more information about this automatic import see: https://docs.openstack.org/i18n/latest/reviewing-translation-import.html Change-Id: Ib11f5c8095c075170575ecaf635e6ce30bd3d789
* Update master for stable/zedOpenStack Release Bot2022-09-092-0/+7
| | | | | | | | | | | | Add file to the reno documentation build to show release notes for stable/zed. Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/zed. Sem-Ver: feature Change-Id: Ib8774b60b82602c4a22c622ebe623e348d0f1f2d
* Only pass exclude-deprecated when True3.12.1whoami-rajat2022-04-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The '--exclude-deprecated' parameter should only be passed to oslo.config to parse when it is True. The final generated sphinx syntax is[1] where [--exclude-deprecated] doesn't require True/False value and only should be passed when True. The change introducing this[2] causes parsing issue in oslo.config[3] while checking <bool>.startswith (we pass True/False value) and even after that while calling argparse[4] with following error[5]. [1] usage: sphinx-build [-h] [--config-dir DIR] [--config-file PATH] [--exclude-deprecated] [--format FORMAT] [--namespace NAMESPACE] [--noexclude-deprecated] [--output-file OUTPUT_FILE] [2] https://review.opendev.org/c/openstack/oslo.policy/+/830514 [3] https://opendev.org/openstack/oslo.config/src/branch/master/oslo_config/cfg.py#L2937 [4] https://opendev.org/openstack/oslo.config/src/branch/master/oslo_config/cfg.py#L2960 [5] > /usr/lib/python3.8/argparse.py(1781)parse_args() -> if argv: (Pdb) > /usr/lib/python3.8/argparse.py(1782)parse_args() -> msg = _('unrecognized arguments: %s') (Pdb) > /usr/lib/python3.8/argparse.py(1783)parse_args() -> self.error(msg % ' '.join(argv)) (Pdb) TypeError: sequence item 0: expected str instance, bool found > /usr/lib/python3.8/argparse.py(1783)parse_args() -> self.error(msg % ' '.join(argv)) Handler <function generate_sample at 0x7fc0d6697d30> for event 'builder-inited' threw an exception (exception: sequence item 0: expected str instance, bool found) Closes-Bug: #1970725 Change-Id: I95745b8d1cbdb6a7cf442d431a998b7e3ff600e4
* Merge "make deprecated rule examples explicit"3.12.0Zuul2022-04-251-0/+19
|\
| * make deprecated rule examples explicitJulia Kreger2022-02-221-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deprecated rules can be confusing and downright unfriendly when evaluating a generated sample output and seeing legacy rules being aliased to new rules. Technically this is also invalid and results in a broken sample file with overriding behavior. Under normal circumstances, this wouldn't be a big deal, but with the Secure RBAC effort, projects also performed some further delineation of RBAC policies instead of performing a 1:1 mapping. As a result of the policy enforcement model, a prior deprecated rule was required, which meant the prior deprecated rule would be reported multiple times in the output. Since we don't have an extra flag in the policy-in-code definitions of policies, all we can *really* do is both clarify the purpose and meaning of the entry, not enable the alias by default in sample output (as it is a sample! not an override of code!), and provide projects as well as operators with a knob to exclude deprecated policy inclusion into examples and sample output. Closes-Bug: #1945336 Change-Id: I6d02eb4d8f94323a806fab991ba2f1c3bbf71d04
* | Update master for stable/yogaOpenStack Release Bot2022-03-042-0/+7
|/ | | | | | | | | | | | Add file to the reno documentation build to show release notes for stable/yoga. Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/yoga. Sem-Ver: feature Change-Id: I35de33c2f540ceb76b0b12da5373545c15306f6d
* Fix formatting of release listPierre Riteau2022-02-071-14/+14
| | | | Change-Id: I09de011b77b49801da2a70eebacfab1d10de32d3
* Enforce scope check always when rule has scope_types set3.10.1Slawek Kaplonski2021-11-231-0/+6
| | | | | | | | | | | | | | | | Previously it was checked only for registered rules but not for rules which are subclasses of the BaseCheck class. Now it's checked for all rules which have scope_types set. It's required for e.g. Neutron as it is creating Check objects based on the defined policy rules to e.g. include in the check attributes like network's provider parameters, etc. Depends-On: https://review.opendev.org/c/openstack/neutron/+/815838 Depends-On: https://review.opendev.org/c/openstack/neutron/+/818725 Closes-Bug: #1923503 Change-Id: I55258c1f999c84220518d1fbbf5e1e514361cebe
* Merge "Rules in policy directory files can be deleted."Zuul2021-10-211-0/+7
|\
| * Rules in policy directory files can be deleted.Mitya_Eremeev2021-10-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Policy directory files can only add new rules or update existing rules in cache, but cannot return back loaded rules in memory to their default value. This incorrect behavior was fixed in the patch. Member "_loaded_files" of class Enforcer should keep list of loaded policy config files paths. In fact if the same file is changed many times then the same file path is added many times. If a file is deleted it's path not deleted from "_loaded_files". The member is very misleading and is not used in code. So this member was deleted in the patch because of above mentioned resons. Change-Id: I9ede38d8cf2ae968d3d8c0b1240bd6a51e6aa931 Closes-Bug: 1943584
* | Merge "Update master for stable/xena"Zuul2021-09-302-0/+7
|\ \
| * | Update master for stable/xenaOpenStack Release Bot2021-09-102-0/+7
| |/ | | | | | | | | | | | | | | | | | | | | | | Add file to the reno documentation build to show release notes for stable/xena. Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/xena. Sem-Ver: feature Change-Id: I90013a56029ff70d0112b56efd32c1d0a5a6f0e0
* | Map system_scope in creds dictionaryMichael Johnson2021-08-121-0/+5
|/ | | | | | | | | | | | | | | | An earlier patch[1] added a mapping for context 'system_scope' to 'system' when enforce was called with a RequestContext object. However, enforce can also be called with a creds dictionary that may contain the context 'system_scope' element. When this occured, 'system_scope' was not mapped to 'system' and the enforce would fail with an InvalidScope exception. This patch moves the 'system_scope' mapping from only occuring with RequestContext objects to also map it when a creds dictonary is passed to enforce. [1] https://review.opendev.org/c/openstack/oslo.policy/+/578995 Change-Id: I83a22c3f825bad0c88018118f8630a20a445965e
* Update master for stable/wallabyOpenStack Release Bot2021-04-152-0/+7
| | | | | | | | | | | | 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: Ic4f96634aa7fe3080c46ef411b7d47778676af1b
* Merge "Add documentation parameters for DeprecatedRule"Zuul2021-02-171-0/+12
|\
| * Add documentation parameters for DeprecatedRuleStephen Finucane2021-01-211-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the way you replace a rule with another rule is by using the 'deprecated_rule' parameter of '(Documented)RuleDefault'. For example: deprecated_rule = policy.DeprecatedRule( name='foo:bar', check_str='role:bazz' ) policy.RuleDefault( name='foo:create_bar', check_str='role:bang', description='Create a bar.', deprecated_rule=deprecated_rule, deprecated_reason='foo:bar has been replaced by foo:create_bar', deprecated_since='N', ) In this instance, we're stating that the 'foo:create_bar' policy replaces the 'foo:bar' policy and we've used (and indeed have to use, to avoid a 'ValueError') the 'deprecated_reason' and 'deprecated_since' parameters on the **new** rule to illustrate why. This is confusing. The new rule clearly isn't the one that's deprecated, so why are we stating the 'deprecated_reason' and 'deprecated_since' there? We can clarify this by instead specifying the reason and timeline on the deprecated rule, like so: deprecated_rule = policy.DeprecatedRule( name='foo:bar', check_str='role:bazz' deprecated_reason='foo:bar has been replaced by foo:create_bar', deprecated_since='N', ) policy.RuleDefault( name='foo:create_bar', check_str='role:bang', description='Create a bar.', deprecated_rule=deprecated_rule, ) Add support for this, with appropriate warnings to nudge people over to the new, improved way of doing things eventually. Change-Id: Ie4809c7749242bd092a2677b7545ef281735d984 Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
* | Merge "remove unicode from code"Zuul2021-02-091-7/+7
|\ \
| * | remove unicode from codexuanyandong2021-01-031-7/+7
| |/ | | | | | | Change-Id: I2837959e8b03f98e8d947787d5c81569fe69acf6
* | Work on copy of registered rule instead of original object3.6.2Ghanshyam Mann2021-02-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When service register their policy rule oslo policy does not copy the rule and instead work on the original object. - https://github.com/openstack/oslo.policy/blob/bd9d47aa36ad6f2f4746f09a267d7ce809a820f4/oslo_policy/policy.py#L1104 policy enforcer modify the default rules in _handle_deprecated_rule(). - https://github.com/openstack/oslo.policy/blob/bd9d47aa36ad6f2f4746f09a267d7ce809a820f4/oslo_policy/policy.py#L767-L774 In any case, oslo policy should make copy of the registered rules. Another thing it fix is setting of flag RuleDefault._deprecated_rule_handled. Flag _deprecated_rule_handled is set to True when _handle_deprecated_rule() is called irrespective of it actually handle the deprecated rule and add it in OR checks. We should set this flag when acutally deprecated rule is handled so that if any condition change like config flag or file rules we correctly handle deprecated rules. Closes-Bug: #1914095 Closes-Bug: #1914592 Story: 2008556 Task: 41687 Change-Id: I154213dabd4d9eef760f0a4c9a852d504638ca8d
* | Handle deprecated rule only once3.6.1Slawek Kaplonski2021-02-011-0/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | The policy engine converts simple strings into instances of rule objects based on a policy DSL. This engine iterates checks and reduces them after each iteration if performing the conversion on list of check strings. When we deprecate policies we apply a logical OR to make upgrades easier for operators. The logical OR, implemented with an OrCheck, only needs to be done once per deprecated rule. Today, we're re-initializing an OrCheck instance each time we load rules, which happens every time oslo_policy.policy.Enforcer.enforce() is called. For most OpenStack usage, this isn't noticiable, especially if you're only using it to enforce access to a specific endpoint. However, this can get expensive if you're using the enforcer to protect the API, protect each resource in a response, and protect each attrbute of the resource (e.g., Neutron makes extensive usage of this pattern to implement RBAC for resources it's responsible for). This commit updates the RuleDefault object to track state of handling deprecated logic ORs so that we only cast the check strings to OrCheck instances once per rule no matter how many times we call load_rules(). Closes-Bug: 1913718 Change-Id: I539672fc220b8d7e3c47ab3dfa6670b88e3f4093
* Update master for stable/victoriaOpenStack Release Bot2020-09-112-0/+7
| | | | | | | | | | | | Add file to the reno documentation build to show release notes for stable/victoria. Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/victoria. Change-Id: Ic9fe5dc1119eee908d0381b89f2c50e86ba4a535 Sem-Ver: feature
* Deprecate the JSON support for policy_fileGhanshyam Mann2020-08-271-0/+12
| | | | | | | | | | | | | | | | | | JSON support for policy_file has been problematic since projects started policy-in-code. For example, generating a sample policy file in JSON results in all the policy-in-code rules being overridden because it is not possible to comment out the default rules in JSON. Asd part of migration of JSON format to YAML, this commit deprecates the: 1. Deprecate JSON support in oslo.policy. 2. Deprecate JSON output in policy CLI tools including '--format' option. Partial implement blueprint policy-json-to-yaml Change-Id: I5432a8cf80903620f48936cbbfb92ea6b6ff30fa
* Add oslopolicy-convert-json-to-yaml toolGhanshyam Mann2020-08-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add ``oslopolicy-convert-json-to-yaml`` tool which can be used to convert the json formatted policy file to yaml format. It takes json formatted policy file as input and convert it to a yaml formatted policy file similar to 'oslopolicy-sample-generator' tool except keeping the overridden rule as uncommented. This tool does the following: * Comment out any rules that match the default from policy-in-code. * Keep rules uncommented if rule is overridden. * Does not auto add the deprecated rules in the file unless it not already present in the file. * Keep any extra rules or already exist deprecated rules uncommented but at the end of the file with a warning text. I did not add the new functionality in existing 'oslopolicy-policy-upgrade' tool because the above listed features of new tool end up creating a complete different code path instead of reusing it from existing tool so it better to have separate tool which can be removed in future once all deployments are migrated to YAML formatted file. This commits add doc and reno also for this tool Partial implement blueprint policy-json-to-yaml Change-Id: Icc245951b2992cc09a891516ffd14f3d4c009920
* Add oslopolicy-validator toolBen Nemec2020-06-261-0/+6
| | | | | | | | | | | | | | | | | | | | As requested in the referenced RFE bug, this is a validator tool similar to the oslo.config validator tool that operators can use to look for basic errors in their policy files. It's very similar to the redundant rule tool, but I decided not to combine them because I feel like the target use cases are enough different to warrant separate tools. Specifically, the redundant rule tool is looking for perfectly valid rules that just happen to be unnecessary. The validator is looking for errors in the policy file. While it's unlikely someone looking for redundant rules wouldn't also want to know if there is something broken in their policy file, it's likely that someone just looking to sanity check their policy before deployment wouldn't want to see a bunch of messages about redundant rules that won't cause any problems. Change-Id: I799a754aceac080c11baffd7ff635b2a9cb825f7 Closes-Bug: 1853038
* Merge "Fix pygments style"3.2.1Zuul2020-06-081-1/+1
|\
| * Fix pygments stylemelissaml2020-06-041-1/+1
| | | | | | | | | | | | | | | | New theme of docs respects pygments_style. more info: http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html Change-Id: I9c03ccdf5dd63f2f13b34f72ebbe8c77168287b6
* | Reload files in policy_dirs on primary file changeDmitrii Shcherbakov2020-06-081-0/+8
|/ | | | | | | | | | | | | | | It was determined that rules from policy files located in the directory specified in the policy_dirs option (/etc/<config_dir>/policy.d by default) are not re-applied after the rules from the primary policy file is re-applied due to a change. This change introduces additional behavior to make sure the rules from policy_dirs are reapplied if there is a change to the primary policy file. Change-Id: I8a6f8e971d881365c41ea409966723319d5b239a Closes-Bug: #1880959 Related-Bug: #1880847
* Switch to newer openstackdocstheme and reno versionsAndreas Jaeger2020-05-181-3/+3
| | | | | | | | | | | | | | | | | | | | Switch to openstackdocstheme 2.2.0 and reno 3.1.0 versions. Using these versions will allow especially: * Linking from HTML to PDF document * Allow parallel building of documents * Fix some rendering Update Sphinx version as well. Remove docs requirements from lower-constraints, they are not needed during install or test but only for docs building. openstackdocstheme renames some variables, so follow the renames before the next release removes them. A couple of variables are also not needed anymore, remove them. Depends-On: https://review.opendev.org/728938 Change-Id: I565a343d875cea144928da007a93f0b93a5d4274
* Update master for stable/ussuriOpenStack Release Bot2020-04-142-0/+7
| | | | | | | | | | | | Add file to the reno documentation build to show release notes for stable/ussuri. Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/ussuri. Change-Id: Id0e367af0c1721a83bec0df102c8e48cf52e1d86 Sem-Ver: feature
* Fix doc comments for new enforce default flagGhanshyam Mann2020-04-091-6/+6
| | | | | | | This commit fixes the review comments from patch - https://review.opendev.org/#/c/717943/ Change-Id: I00edbea503aefbce31cbb43a74929db752235bf0
* Add new config to enforce the new defaultsGhanshyam Mann2020-04-071-0/+11
| | | | | | | | | | | | | | | | | | | | When policy change their default check_str and not override by operator then old defaults check_str are added with OrCheck to the new default check_str so that old defaults keep working. If operators want to enforce the new defaults with no old defaults then they have to overwrite the policy rule in poicy file with new default value. This is not expected and very painful for them especially when all policies are switching to new defaults. For example: - https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:open+OR+status:merged) This commit adds a new config options to control the new defaults enforcement. If True then old defaults will not be supported and also no warning will be logged. New config option is default to False so no change in behaviour for old users. Change-Id: I3c2c889af25b723f1eedbe6167d614c6a4bc6cd2
* [ussuri][goal] Drop python 2.7 support and testingHervé Beraud2020-02-061-0/+5
| | | | | | | | | | | | | | OpenStack is dropping the py2.7 support in Ussuri cycle. Complete discussion & schedule can be found in - http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010142.html - https://etherpad.openstack.org/p/drop-python2-support Ussuri Communtiy-wide goal: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html Change-Id: If6a07eee86a2aaf65bdf9fbb338809ad47e02a46
* Bump the openstackdocstheme extension to 1.20pengyuesheng2019-11-121-13/+0
| | | | | | | | | | | | Some options are now automatically configured by the version 1.20: - project - html_last_updated_fmt - latex_engine - latex_elements - version - release. Change-Id: I2c9f7b72a52edde7b18dc66bcc8c655630b3bbc2
* Merge "Suppress deprecation warnings in oslopolicy-list-redundant"Zuul2019-10-101-0/+6
|\
| * Suppress deprecation warnings in oslopolicy-list-redundantBen Nemec2019-09-171-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running the tool against a project with a lot of deprecated policies, the deprecation warnings overwhelm the important output from the tool. Since checking for deprecations isn't the purpose of this tool, let's just suppress warnings and limit the output to the list of redundant policy rules that the user cares about. I will note that the suppress_deprecation_warnings member is marked as test only, but that was targeted at consumers of oslo.policy rather than oslo.policy itself. I could also argue that we're "testing" for redundant policies here, but that feels like semantic hair splitting. :-) Change-Id: I194af14ebd341366dbb1dd033654739a7f3d085c Partial-Bug: 1836568
* | Update master for stable/trainOpenStack Release Bot2019-09-202-0/+7
|/ | | | | | | | | | | | Add file to the reno documentation build to show release notes for stable/train. Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/train. Change-Id: I8cb1d87c0a6ab7da1918e69cd52fd40276717d5b Sem-Ver: feature
* Update master for stable/steinOpenStack Release Bot2019-03-182-0/+7
| | | | | | | | | | | | Add file to the reno documentation build to show release notes for stable/stein. Use pbr instruction to increment the minor version number automatically so that master versions are higher than the versions on stable/stein. Change-Id: I4ab63935e8382bd0e5903297f2a5cd424884b38b Sem-Ver: feature
* Add policy-upgrade toolwangxiyuan2018-12-111-0/+6
| | | | | | | | Add a new "oslopolicy-policy-upgrade" commnd. Using this command, operator can upgrade their self-defined policy files to follow the new format in the new release when upgrading OpenStack services. Change-Id: Iad9740bd8a5e4fdf1d1e64d61bc93f2483c531f3
* Add ability to pass in target data for the oslopolicy-checker1.41.0Juan Antonio Osorio Robles2018-11-021-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | This allows us to test the policy for other services which might have different or unusual target data formats (such as Barbican). It would be possible to pass it as a nested dictionary, e.g.: { "target": { "secret": { "project_id": "my project id" } } } or as a key pair (as oslo.policy would expect): { "target.secret.project_id": "my project id" } Both will work (note that this logic was taken from barbican). This fixes around the limitation that the target is hardcoded to be "project_id", and thus allows to test more scenarios (such as the project ID not matching). Change-Id: Ia9f7462072a8cb142251c8bb5ef19d9a25a98119
* Imported Translations from ZanataOpenStack Proposal Bot2018-08-091-3/+77
| | | | | | | For more information about this automatic import see: https://docs.openstack.org/i18n/latest/reviewing-translation-import.html Change-Id: I3919b7000ca46212d17a4e9e7c3fea55ed74cd78
* Update reno for stable/rockyOpenStack Release Bot2018-07-262-0/+7
| | | | Change-Id: I40d2c2007c9cf3b372d44f8915567da33a048472
* Merge "Avoid redundant policy syntax checks"rocky-em1.38.1Zuul2018-07-191-0/+7
|\
| * Avoid redundant policy syntax checksMateusz Kowalski2018-07-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a private variable inside Enforcer class to remember status of the last policy syntax checks in order to avoid redundant calls to the check_rules() method. Having this flag makes the whole rules mechanism faster, as under certain conditions check_rules() method was being executed multiple times even when not needed. Change-Id: Id3992fc0cb567451049a12ebdc6851e737573bb8 Closes-bug: #1723030 Co-Authored-By: Ben Nemec <bnemec@redhat.com>
* | Teach Enforcer.enforce to deal with context objectsLance Bragstad2018-07-091-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | The ``creds`` dictionary passed into oslo.policy's enforce() method assumes a lot of the same values already specified by oslo.context RequestContext objects. This commit teaches enforce() to handle being passed an instance of a RequestContext object, and populate credential values accordingly. Change-Id: Ia74bf6c40b1e05a1c958f4325e00f68be28d91b9 Closes-Bug: 1779172
* | Merge "Add CLI usage documentation"Zuul2018-06-071-0/+6
|\ \
| * | Add CLI usage documentationLance Bragstad2018-06-011-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | This commit adds usage and examples for generating sample policy files and listing redundant policy rules. Change-Id: I2ff00a0a038fde5596ec2fe35de1b7647efcbb9c Closes-Bug: 1741073
* | | Merge "Remove erroneous newline in sample generation"1.37.0Zuul2018-06-041-0/+6
|\ \ \
| * | | Remove erroneous newline in sample generationLance Bragstad2018-06-011-0/+6
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sample generation code for policies has a couple different cases that make sure deprecated rules have descriptions and reasoning formatted in the comment section. One of the cases that handles policies deprecated for removal was injecting an extra newline in the comment text that threw off the formatting of the sample, leaving the subsequent policy uncommented, and visually unpleasing. This commit removes the extra newline in the formatting logic for deprecated policies and adds a test case for the behavior. Change-Id: I76338d2fbaccf3b43e0da04732fd9df3c05dfbda Closes-Bug: 1771442
* | | Update sphinxext to include scope_types in docsLance Bragstad2018-06-011-0/+6
|/ / | | | | | | | | | | | | | | | | | | | | Since we've added ``scope_types`` as an attribute to policy rules, it makes sense to include this information in documentation. End users will need to know what type of scope is required to pass a specific policy rule when services start incorporating system scope and scope types. Change-Id: I86d89e9f45740b39cef04773cec8846c1ab97c3a Closes-Bug: 1773473
View Lorry Controller Status