)]}'
{"defaults/main.yml":[{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"7927ed7eb82380f2bf51a1168bc1ea92ec76e7b4","unresolved":false,"context_lines":[{"line_number":452,"context_line":"# template engine and copied to the target host. If they do"},{"line_number":453,"context_line":"# not exist then the default files will be sourced from the"},{"line_number":454,"context_line":"# service git repository."},{"line_number":455,"context_line":"keystone_paste_default_file_path: \"/etc/openstack_deploy/keystone/keystone-paste.ini\""},{"line_number":456,"context_line":"keystone_policy_default_file_path: \"/etc/openstack_deploy/keystone/policy.json\""},{"line_number":457,"context_line":"keystone_sso_callback_file_path: \"/etc/openstack_deploy/keystone/sso_callback_template.html\""},{"line_number":458,"context_line":""}],"source_content_type":"text/x-yaml","patch_set":10,"id":"dfeb2761_19721aae","line":455,"range":{"start_line":455,"start_character":57,"end_line":455,"end_character":65},"updated":"2017-04-05 09:52:41.000000000","message":"to avoid having a mess of many directories that ppl don\u0027t really know what they are for, I\u0027d rather have a keystone folder inside a single folder.\n\nTherefore \"/etc/openstack_deploy/file_distribution/keystone/ ...\"\n\nThis way file_distribution is a \"thing\" like we\u0027d do \"confd\", \"envd\", \"group_vars\", \"host_vars\", or \"ansible_facts\". Keeping things clean!","commit_id":"ffcdaf0c92dd57c90a71162495fb6cac006a1513"}],"handlers/main.yml":[{"author":{"_account_id":2799,"name":"Andy McCrae","email":"andy.mccrae@googlemail.com","username":"andrew-mccrae"},"change_message_id":"5e522cf13acd8f5da2e28ef65a12907f990d4be4","unresolved":false,"context_lines":[{"line_number":21,"context_line":"  notify:"},{"line_number":22,"context_line":"    - Stop Apache"},{"line_number":23,"context_line":"    - Stop Nginx"},{"line_number":24,"context_line":"    - Stop uWSGI"},{"line_number":25,"context_line":"    - Copy the latest policy file into place"},{"line_number":26,"context_line":"    - Start uWSGI"},{"line_number":27,"context_line":"    - Start Nginx"}],"source_content_type":"text/x-yaml","patch_set":5,"id":"ffe62b97_221d7573","line":24,"range":{"start_line":24,"start_character":11,"end_line":24,"end_character":16},"updated":"2017-03-29 13:18:07.000000000","message":"Were going to need to come up with a better way to do this I think.\nThis is pretty similar to how it is for now - but the issue is that co-located services with nginx/apache will stop apache/nginx for ALL of them while keystone does it\u0027s restart thing.\n\nCan we get clever with reloads? Perhaps this means we have to move away from wsgi --\u003e uwsgi permanently (since that would then be the service that needs a restart - nginx/apache doesn\u0027t do the conf reading)\n\nThe end result would then be: \nReload Apache/Nginx\nStop uWSGI\nDrop file\nStart uWSGI\n\nOr even better - treat nginx/apache as a separate entity (since it wouldn\u0027t actually control the service and would just be a proxy), and then do something like:\n\nReload uWSGI\nDrop file\n\nThe issue seems to be that we need the updated version of Keystone in order to successfully read the policy file? The reload of uWSGI will ensure that keystone starts with the old policy file, then dropping the new policy file will ensure that works successfully.\n\nThis also raises the need to improve our health checks for services (using haproxy for example) - a simple port check won\u0027t work if we\u0027re fronting with apache/nginx passing to uwsgi (wait for keystone service port a key example of that).","commit_id":"bce01e8b6b1e89efc812b878223ee195ecaa52fb"},{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"bbcee36bcb60a3931106e0615235eacdd7f8a77f","unresolved":false,"context_lines":[{"line_number":21,"context_line":"  notify:"},{"line_number":22,"context_line":"    - Stop Apache"},{"line_number":23,"context_line":"    - Stop Nginx"},{"line_number":24,"context_line":"    - Stop uWSGI"},{"line_number":25,"context_line":"    - Copy the latest policy file into place"},{"line_number":26,"context_line":"    - Start uWSGI"},{"line_number":27,"context_line":"    - Start Nginx"}],"source_content_type":"text/x-yaml","patch_set":5,"id":"ffe62b97_2f441c73","line":24,"range":{"start_line":24,"start_character":11,"end_line":24,"end_character":16},"in_reply_to":"ffe62b97_221d7573","updated":"2017-03-30 06:54:26.000000000","message":"The issue is partially that, as jesse wrote: \"The policy.json file is currently read continually by the services and is not only read on service start. We therefore cannot template directly to the file read by the service (if the service is already running) because the new policies\nmay not be valid until the service restarts.\"\n\nDuring upgrades, here an empty policy is templated, and therefore the old (here keystone) code try to re-read the (newly emptied) policy file, and fails.\n\nI think the code generally achieves that, because we are now swapping the policy file after everything has been restarted. We\u0027ll only be stuck if NEW code cannot read OLD policy file, vs the previous OLD code cannot read NEW policy file. For me it\u0027s trading between two bad things, but at least it\u0027s gonna be working for our upgrades.\n\nIdeally:\n- Keystone should lock to its policy file and only read on demand (I mean when we want it :p)\n- We should revision files, this way code version x works with code configuration x, with no rolling. An update of code to version y will require a configuration change y (so break of idempotency anyway). We could therefore use a \"code version\" as basis for runtime config.\n- We could have a way to orchestrate the process better, by making sure old code doesn\u0027t get new requests starting when new configuration is done.\n\nAlternatively:\nWe can accept the idea that this kind of small window downtime can occur when doing an upgrade.\n\nFor the other topics:\n\nSo for the generic/specific handler behavior we could use handler binding, with a generic binding for reload (reload webserver), and a more specific one in certain cases (reload apache).\n\nI\u0027m all in for uWSGI, maybe we should invest time in doing this properly and set a pattern. But I\u0027m not sure it\u0027s resolving anything in here.\n\nIs there a way in uWSGI to lock files/version runtime files for the running code?\n\nFor the last part, the improvement of health checks, maybe it\u0027s not worth to have this intermediary anymore. If all we are looking into nginx/apache is log files handling and https termination, we can pretty much have alternatives. If it\u0027s for federation: apache + mod_shib has maybe alternatives and Keystone team could maybe help us there.","commit_id":"bce01e8b6b1e89efc812b878223ee195ecaa52fb"}],"releasenotes/notes/keystone-upstream-config-files-d16f27fc1332ed83.yaml":[{"author":{"_account_id":17068,"name":"Jean-Philippe Evrard","email":"openstack@a.spamming.party","username":"evrardjp"},"change_message_id":"7927ed7eb82380f2bf51a1168bc1ea92ec76e7b4","unresolved":false,"context_lines":[{"line_number":4,"context_line":"    ``keystone-paste.ini``, ``policy.json`` and ``sso_callback_template.html``"},{"line_number":5,"context_line":"    templates from the service git source instead of from the role. It also"},{"line_number":6,"context_line":"    now includes a facility where you can place your own templates in"},{"line_number":7,"context_line":"    ``/etc/openstack_deploy/keystone`` (by default) and it will be"},{"line_number":8,"context_line":"    deployed to the target host after being interpreted by the"},{"line_number":9,"context_line":"    template engine."}],"source_content_type":"text/x-yaml","patch_set":10,"id":"dfeb2761_b918ce1d","line":7,"updated":"2017-04-05 09:52:41.000000000","message":"file_distribution/","commit_id":"ffcdaf0c92dd57c90a71162495fb6cac006a1513"}],"tasks/keystone_post_install.yml":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"a51151e6eb80d5d3880f4bb6efdeac0bf2aaa470","unresolved":false,"context_lines":[{"line_number":45,"context_line":"      config_type: \"ini\""},{"line_number":46,"context_line":"      content: |"},{"line_number":47,"context_line":"        cat {{ keystone_paste_default_file_path }} 2\u003e/dev/null || \\"},{"line_number":48,"context_line":"        curl -s {{ keystone_git_config_lookup_location }}/{{ keystone_paste_git_file_path }}"},{"line_number":49,"context_line":"    - dest: \"/etc/keystone/policy.json\""},{"line_number":50,"context_line":"      config_overrides: \"{{ keystone_policy_overrides }}\""},{"line_number":51,"context_line":"      config_type: \"json\""}],"source_content_type":"text/x-yaml","patch_set":1,"id":"ffe62b97_28b34b9a","line":48,"updated":"2017-03-28 14:11:09.000000000","message":"We are planning on removing this file as a part of moving policy into code [0]. Instead, we plan on providing a way to generate a default policy using oslo-policy (`oslopolicy-sample-generator`) [1].\n\n\n[0] https://review.openstack.org/#/c/448826/\n[1] https://review.openstack.org/#/c/443344/","commit_id":"0c8803e5f947c54a7ebf94119f7ef9de3145f4ae"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"7ca4ece96660b7039fd0186bb140a611cf6b56ba","unresolved":false,"context_lines":[{"line_number":45,"context_line":"      config_type: \"ini\""},{"line_number":46,"context_line":"      content: |"},{"line_number":47,"context_line":"        cat {{ keystone_paste_default_file_path }} 2\u003e/dev/null || \\"},{"line_number":48,"context_line":"        curl -s {{ keystone_git_config_lookup_location }}/{{ keystone_paste_git_file_path }}"},{"line_number":49,"context_line":"    - dest: \"/etc/keystone/policy.json\""},{"line_number":50,"context_line":"      config_overrides: \"{{ keystone_policy_overrides }}\""},{"line_number":51,"context_line":"      config_type: \"json\""}],"source_content_type":"text/x-yaml","patch_set":1,"id":"ffe62b97_c3a5e048","line":48,"in_reply_to":"ffe62b97_28b34b9a","updated":"2017-03-28 14:30:24.000000000","message":"Thanks for the update - great to see this happening! I\u0027ll do a follow up patch to change the sourcing of the policy file. This is establishing a pattern which I want to replicate across the other service roles and seeing as they all haven\u0027t done the same as keystone/nova for policy.json files (yet) I\u0027d prefer to keep this here for now.","commit_id":"0c8803e5f947c54a7ebf94119f7ef9de3145f4ae"},{"author":{"_account_id":7353,"name":"Kevin Carter","email":"kevin@cloudnull.com","username":"cloudnull"},"change_message_id":"d1c1c763b4a08ac4f677fa2a15136faec8d95ac5","unresolved":false,"context_lines":[{"line_number":44,"context_line":"      config_overrides: \"{{ keystone_keystone_paste_ini_overrides }}\""},{"line_number":45,"context_line":"      config_type: \"ini\""},{"line_number":46,"context_line":"      content: |"},{"line_number":47,"context_line":"        cat {{ keystone_paste_default_file_path }} 2\u003e/dev/null || \\"},{"line_number":48,"context_line":"        curl -s {{ keystone_git_config_lookup_location }}/{{ keystone_paste_git_file_path }}"},{"line_number":49,"context_line":"    - dest: \"/etc/keystone/policy.json-{{ keystone_venv_tag }}\""},{"line_number":50,"context_line":"      config_overrides: \"{{ keystone_policy_overrides }}\""}],"source_content_type":"text/x-yaml","patch_set":9,"id":"dfeb2761_a97e7316","line":47,"updated":"2017-04-04 02:47:51.000000000","message":"I rather hate the bash to lookup to pipe to string however i\u0027m not seeing a better way forward.","commit_id":"e925ba928ba3da3c0fe562a2e8019132feadd1cb"},{"author":{"_account_id":6816,"name":"Jesse Pretorius","email":"jesse@odyssey4.me","username":"jesse-pretorius"},"change_message_id":"a9180d6a5eac2b475cca94e64b503432440bc3a3","unresolved":false,"context_lines":[{"line_number":44,"context_line":"      config_overrides: \"{{ keystone_keystone_paste_ini_overrides }}\""},{"line_number":45,"context_line":"      config_type: \"ini\""},{"line_number":46,"context_line":"      content: |"},{"line_number":47,"context_line":"        cat {{ keystone_paste_default_file_path }} 2\u003e/dev/null || \\"},{"line_number":48,"context_line":"        curl -s {{ keystone_git_config_lookup_location }}/{{ keystone_paste_git_file_path }}"},{"line_number":49,"context_line":"    - dest: \"/etc/keystone/policy.json-{{ keystone_venv_tag }}\""},{"line_number":50,"context_line":"      config_overrides: \"{{ keystone_policy_overrides }}\""}],"source_content_type":"text/x-yaml","patch_set":9,"id":"dfeb2761_a549ef8b","line":47,"in_reply_to":"dfeb2761_a97e7316","updated":"2017-04-04 10:03:53.000000000","message":"Yeah, the only other way I could see doing this would be to instrument something like with_first_found to be able to find the first available source, being a file on the deployment node, a file at an http source or the raw contents of a var (now that keystone have removed policy.json from their git tree).","commit_id":"e925ba928ba3da3c0fe562a2e8019132feadd1cb"}],"templates/policy.json.j2":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"e2818b8357e8593214f0b9a6e50c30f5fb42dab3","unresolved":false,"context_lines":[{"line_number":1,"context_line":"{"},{"line_number":2,"context_line":"    \"admin_required\": \"role:admin or is_admin:1\","},{"line_number":3,"context_line":"    \"service_role\": \"role:service\","},{"line_number":4,"context_line":"    \"service_or_admin\": \"rule:admin_required or rule:service_role\","}],"source_content_type":"text/x-jinja2","patch_set":10,"id":"bff0334d_348a5d69","side":"PARENT","line":1,"updated":"2017-04-11 19:59:49.000000000","message":"YAS!","commit_id":"94293c86c296c2f5c8a2492e1348bca1278ef3ec"}]}