)]}'
{"doc/source/reference/policy-enforcement.rst":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"50a7dac75c1dcb17f01cbf30d7aaec87428a6cd9","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Group the policy rules into different policy files"},{"line_number":117,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"After group the policy rules for different API, we can separate them into"},{"line_number":120,"context_line":"different files. Then deployer will more clear for which rule he can set for"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_e71434eb","line":117,"updated":"2019-03-18 13:59:03.000000000","message":"I\u0027m not entirely sure I have all the context around this bit, yet. Is this something that nova still wants to do? With default policies and registering them in code, is this still needed?","commit_id":"0f1b2e3a63d8d87f3ed3ea53f02a0254b7e5af66"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"555d1ec5a1f19012b71011d1fc260b9a62066eca","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Group the policy rules into different policy files"},{"line_number":117,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"After group the policy rules for different API, we can separate them into"},{"line_number":120,"context_line":"different files. Then deployer will more clear for which rule he can set for"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_ca757d33","line":117,"in_reply_to":"5fc1f717_2a48c12a","updated":"2019-03-18 14:40:31.000000000","message":"I had also assumed that policy_dirs enabled this, i.e. pulling policy rules from different policy files in different directories, but I must be missing something.","commit_id":"0f1b2e3a63d8d87f3ed3ea53f02a0254b7e5af66"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"44f6f419487d2b888ce1b05b33a5e1d96d8d98d5","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Group the policy rules into different policy files"},{"line_number":117,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"After group the policy rules for different API, we can separate them into"},{"line_number":120,"context_line":"different files. Then deployer will more clear for which rule he can set for"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_0925ca08","line":117,"in_reply_to":"5fc1f717_ca757d33","updated":"2019-03-18 19:15:05.000000000","message":"\u003e I had also assumed that policy_dirs enabled this, i.e. pulling\n \u003e policy rules from different policy files in different directories,\n \u003e but I must be missing something.\n\nYeah - me, too. I have yet to see policy_dirs used in an real-world example.","commit_id":"0f1b2e3a63d8d87f3ed3ea53f02a0254b7e5af66"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c63371af23bb669cec6dd1a29fa4f8a42ac5dfba","unresolved":false,"context_lines":[{"line_number":114,"context_line":""},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"Group the policy rules into different policy files"},{"line_number":117,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"After group the policy rules for different API, we can separate them into"},{"line_number":120,"context_line":"different files. Then deployer will more clear for which rule he can set for"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fc1f717_2a48c12a","line":117,"in_reply_to":"5fc1f717_e71434eb","updated":"2019-03-18 14:37:13.000000000","message":"I\u0027m not sure either. EC2 APIs are out of tree so we don\u0027t really care about that. It is still possible to expose a v2.0 endpoint in the service catalog and there is a LegacyV2CompatibleWrapper middleware in the api-paste.ini, but the handler code is all the same, so the policy rules are the same, so there isn\u0027t a point in splitting policy by v2.0 and v2.1.\n\nWhich means if you wanted to further break things down, you\u0027d do it by route/resource or something, or admin vs non-admin APIs, but I\u0027m not aware of anyone that does that or wants to do that. Plus as you said, with defaults in code, overriding what you want in the single policy file seems good enough for organizational purposes.\n\nIDK, maybe would need to ask the patrole people what they think about this, or operators list.","commit_id":"0f1b2e3a63d8d87f3ed3ea53f02a0254b7e5af66"}]}
