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