Felipe Monteiro | 8a5f69a | 2017-07-14 20:12:33 +0100 | [diff] [blame] | 1 | .. _patrole-configuration: |
| 2 | |
| 3 | Patrole Configuration Guide |
| 4 | =========================== |
| 5 | |
| 6 | Patrole can be customized by updating Tempest's ``tempest.conf`` configuration |
| 7 | file. All Patrole-specific configuration options should be included under |
Felipe Monteiro | f6eb862 | 2017-08-06 06:08:02 +0100 | [diff] [blame] | 8 | the ``patrole`` group. |
Felipe Monteiro | 8a5f69a | 2017-07-14 20:12:33 +0100 | [diff] [blame] | 9 | |
Mykola Yakovliev | e0f3550 | 2018-09-26 18:26:57 -0500 | [diff] [blame] | 10 | RBAC Test Roles |
| 11 | --------------- |
Felipe Monteiro | 8a5f69a | 2017-07-14 20:12:33 +0100 | [diff] [blame] | 12 | |
Mykola Yakovliev | e0f3550 | 2018-09-26 18:26:57 -0500 | [diff] [blame] | 13 | The RBAC test roles govern the list of roles to be used when running Patrole |
| 14 | tests. For example, setting ``rbac_test_roles`` to "admin" will execute all |
| 15 | RBAC tests using admin credentials. Changing the ``rbac_test_roles`` value |
| 16 | will `override` Tempest's primary credentials to use that role. |
Felipe Monteiro | 8a5f69a | 2017-07-14 20:12:33 +0100 | [diff] [blame] | 17 | |
Mykola Yakovliev | e0f3550 | 2018-09-26 18:26:57 -0500 | [diff] [blame] | 18 | This implies that, if ``rbac_test_roles`` is "admin", regardless of the Tempest |
Felipe Monteiro | 8a5f69a | 2017-07-14 20:12:33 +0100 | [diff] [blame] | 19 | credentials used by a client, the client will be calling APIs using the admin |
| 20 | role. That is, ``self.os_primary.servers_client`` will run as though it were |
| 21 | ``self.os_admin.servers_client``. |
| 22 | |
Mykola Yakovliev | e0f3550 | 2018-09-26 18:26:57 -0500 | [diff] [blame] | 23 | Similarly, setting ``rbac_test_roles`` with various roles, results in |
| 24 | Tempest's primary credentials being overridden by the roles specified by |
| 25 | ``rbac_test_roles``. |
Felipe Monteiro | 8a5f69a | 2017-07-14 20:12:33 +0100 | [diff] [blame] | 26 | |
| 27 | .. note:: |
| 28 | |
Mykola Yakovliev | e0f3550 | 2018-09-26 18:26:57 -0500 | [diff] [blame] | 29 | Only the roles of the primary Tempest credentials ("os_primary") are |
Felipe Monteiro | 8a5f69a | 2017-07-14 20:12:33 +0100 | [diff] [blame] | 30 | modified. The ``user_id`` and ``project_id`` remain unchanged. |
| 31 | |
Felipe Monteiro | 8a5f69a | 2017-07-14 20:12:33 +0100 | [diff] [blame] | 32 | Custom Policy Files |
| 33 | ------------------- |
| 34 | |
| 35 | Patrole supports testing custom policy file definitions, along with default |
| 36 | policy definitions. Default policy definitions are used if custom file |
| 37 | definitions are not specified. If both are specified, the custom policy |
| 38 | definition takes precedence (that is, replaces the default definition, |
| 39 | as this is the default behavior in OpenStack). |
| 40 | |
| 41 | The ``custom_policy_files`` option allows a user to specify a comma-separated |
| 42 | list of custom policy file locations that are on the same host as Patrole. |
| 43 | Each policy file must include the name of the service that is being tested: |
| 44 | for example, if "compute" tests are executed, then Patrole will use the first |
| 45 | policy file contained in ``custom_policy_files`` that contains the "nova" |
| 46 | keyword. |
| 47 | |
| 48 | .. note:: |
| 49 | |
| 50 | Patrole currently does not support policy files located on a host different |
| 51 | than the one on which it is running. |
Felipe Monteiro | 9ae705d | 2018-03-26 22:14:44 -0400 | [diff] [blame] | 52 | |
| 53 | Policy Feature Flags |
| 54 | -------------------- |
| 55 | |
| 56 | Patrole's ``[policy-feature-enabled]`` configuration group includes one option |
| 57 | per supported policy feature flag. These feature flags are introduced when an |
| 58 | OpenStack service introduces a new policy or changes a policy in a |
| 59 | backwards-incompatible way. Since Patrole is branchless, it copes with the |
| 60 | unexpected policy change by making the relevant policy change as well, but |
| 61 | also introduces a new policy feature flag so that the test won't break N-1/N-2 |
| 62 | releases where N is the currently supported release. |
| 63 | |
| 64 | The default value for the feature flag is enabled for N and disabled for any |
| 65 | releases prior to N in which the feature is not available. This is done by |
| 66 | overriding the default value of the feature flag in DevStack's ``lib/patrole`` |
| 67 | installation script. The change is made in Tempest's DevStack script because |
| 68 | Patrole's DevStack plugin is hosted in-repo, which is branch-less (whereas |
| 69 | the former is branched). |
| 70 | |
| 71 | After the backwards-incompatible change no longer affects any supported |
| 72 | release, then the corresponding policy feature flag is removed. |
| 73 | |
| 74 | For more information on feature flags, reference the relevant |
| 75 | `Tempest documentation`_. |
| 76 | |
zhufl | 788db67 | 2019-05-13 17:33:32 +0800 | [diff] [blame] | 77 | .. _Tempest documentation: https://docs.openstack.org/tempest/latest/HACKING.html#new-tests-for-new-features |
Felipe Monteiro | 9ae705d | 2018-03-26 22:14:44 -0400 | [diff] [blame] | 78 | |
| 79 | Sample Configuration File |
| 80 | ------------------------- |
| 81 | |
| 82 | The following is a sample Patrole configuration for adaptation and use. It is |
| 83 | auto-generated from Patrole when this documentation is built, so |
| 84 | if you are having issues with an option, please compare your version of |
| 85 | Patrole with the version of this documentation. |
| 86 | |
| 87 | Note that the Patrole configuration options actually live inside the Tempest |
| 88 | configuration file; at runtime, Tempest populates its own configuration |
| 89 | file with Patrole groups and options, assuming that Patrole is correctly |
| 90 | installed and recognized as a plugin. |
| 91 | |
| 92 | The sample configuration can also be viewed in `file form <_static/patrole.conf.sample>`_. |
| 93 | |
| 94 | .. literalinclude:: _static/patrole.conf.sample |