)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":15993,"name":"Amy Marrich","display_name":"Amy Marrich (spotz)","email":"amy@demarco.com","username":"amarrich"},"change_message_id":"46e0ecdf7d08430cef1b95c41331349e7af08c14","unresolved":false,"context_lines":[{"line_number":7,"context_line":"Add rolling upgrade documentation"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This documentation conflicts a bit with the approach originally proposed"},{"line_number":10,"context_line":"in bp manage-migration because it depends on the notion of having a"},{"line_number":11,"context_line":"database triggers to assist in the migration process."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Change-Id: Iec9269ab6d799b757451cb8afe7fa889fe7068b9"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"9ad45d7e_e52ea88a","line":11,"range":{"start_line":10,"start_character":66,"end_line":11,"end_character":17},"updated":"2016-08-11 15:26:36.000000000","message":"If it\u0027s a single DB trigger - a database trigger\nIf it\u0027s multiple triggers - database triggers - removing the a","commit_id":"b11d52947f928b6bc1300088423d614e29cad119"}],"doc/source/upgrading.rst":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"b42104b1f5d861f20275e134da3327022471a2dd","unresolved":false,"context_lines":[{"line_number":46,"context_line":""},{"line_number":47,"context_line":"2. Stop all keystone processes. If you only upgrade one node at a time,"},{"line_number":48,"context_line":"   then you\u0027ll risk multiple releases of keystone trying to write to the"},{"line_number":49,"context_line":"   database at the same time."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"3. Make a backup of your database. Keystone does not support downgrading the"},{"line_number":52,"context_line":"   database, so restoring from a full backup is your only option for recovery"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_79c8e122","side":"PARENT","line":49,"updated":"2016-08-04 19:19:34.000000000","message":"Do we want to elaborate on *why* this would be risky?","commit_id":"aae0571b8011bb50ce2c946d838f0955794d1337"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"145e59ba69d85dfc6ca2a2b37794ef87bd8f975f","unresolved":false,"context_lines":[{"line_number":46,"context_line":""},{"line_number":47,"context_line":"2. Stop all keystone processes. If you only upgrade one node at a time,"},{"line_number":48,"context_line":"   then you\u0027ll risk multiple releases of keystone trying to write to the"},{"line_number":49,"context_line":"   database at the same time."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"3. Make a backup of your database. Keystone does not support downgrading the"},{"line_number":52,"context_line":"   database, so restoring from a full backup is your only option for recovery"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_35b8fa10","side":"PARENT","line":49,"in_reply_to":"bacf61ea_79c8e122","updated":"2016-08-05 15:38:00.000000000","message":"I\u0027m not sure how to explain it concisely, but I\u0027ll give it a shot. Suggestions welcome.","commit_id":"aae0571b8011bb50ce2c946d838f0955794d1337"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8c23024de933b1581678e2d592b03a8d5a9c035c","unresolved":false,"context_lines":[{"line_number":19,"context_line":"As of the Newton release, keystone supports two different approaches to"},{"line_number":20,"context_line":"upgrading across releases. The traditional approach requires a significant"},{"line_number":21,"context_line":"outage to be scheduled for the entire duration of the upgrade process. The more"},{"line_number":22,"context_line":"modern approach requires zero downtime but limits the available capabilities of"},{"line_number":23,"context_line":"the service during the upgrade process."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":".. NOTE::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_1fd9d422","line":22,"updated":"2016-08-04 14:59:20.000000000","message":"It might be useful to say that it is more complicated and overall takes more time somewhere.","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"a1725547c9c97e3bb137aae53f26dd55d216f855","unresolved":false,"context_lines":[{"line_number":19,"context_line":"As of the Newton release, keystone supports two different approaches to"},{"line_number":20,"context_line":"upgrading across releases. The traditional approach requires a significant"},{"line_number":21,"context_line":"outage to be scheduled for the entire duration of the upgrade process. The more"},{"line_number":22,"context_line":"modern approach requires zero downtime but limits the available capabilities of"},{"line_number":23,"context_line":"the service during the upgrade process."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":".. NOTE::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_aa14c14c","line":22,"in_reply_to":"bacf61ea_1fd9d422","updated":"2016-08-04 17:22:06.000000000","message":"You mean, in addition to or instead of what I said? Here\u0027s my attempt at in-addition-to:\n\n  The more modern approach requires zero downtime, but is more\n  complicated resulting in a longer upgrade process and limits the\n  available capabilities the service during a portion of the process.","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"e0623383c0f6e5c85d497ccb2cbe7e3aada7aee2","unresolved":false,"context_lines":[{"line_number":19,"context_line":"As of the Newton release, keystone supports two different approaches to"},{"line_number":20,"context_line":"upgrading across releases. The traditional approach requires a significant"},{"line_number":21,"context_line":"outage to be scheduled for the entire duration of the upgrade process. The more"},{"line_number":22,"context_line":"modern approach requires zero downtime but limits the available capabilities of"},{"line_number":23,"context_line":"the service during the upgrade process."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":".. NOTE::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_5442f83e","line":22,"in_reply_to":"bacf61ea_39c2e934","updated":"2016-08-05 00:07:20.000000000","message":"@Dolph, Yep I think you are on the right track here. \n\n@Lance, I like your changes too.","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"145e59ba69d85dfc6ca2a2b37794ef87bd8f975f","unresolved":false,"context_lines":[{"line_number":19,"context_line":"As of the Newton release, keystone supports two different approaches to"},{"line_number":20,"context_line":"upgrading across releases. The traditional approach requires a significant"},{"line_number":21,"context_line":"outage to be scheduled for the entire duration of the upgrade process. The more"},{"line_number":22,"context_line":"modern approach requires zero downtime but limits the available capabilities of"},{"line_number":23,"context_line":"the service during the upgrade process."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":".. NOTE::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_95d5661d","line":22,"in_reply_to":"bacf61ea_5442f83e","updated":"2016-08-05 15:38:00.000000000","message":"I can see an argument for both \"results\" or \"requires,\" because while it does not result in any downtime as written, you could optionally do the expand-migrate-contract process with downtime if you chose.","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"b42104b1f5d861f20275e134da3327022471a2dd","unresolved":false,"context_lines":[{"line_number":19,"context_line":"As of the Newton release, keystone supports two different approaches to"},{"line_number":20,"context_line":"upgrading across releases. The traditional approach requires a significant"},{"line_number":21,"context_line":"outage to be scheduled for the entire duration of the upgrade process. The more"},{"line_number":22,"context_line":"modern approach requires zero downtime but limits the available capabilities of"},{"line_number":23,"context_line":"the service during the upgrade process."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":".. NOTE::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_39c2e934","line":22,"in_reply_to":"bacf61ea_aa14c14c","updated":"2016-08-04 19:19:34.000000000","message":"The more modern approach requires zero downtime? Wouldn\u0027t it be that the more modern approach *results* in zero downtime (but at the expense of being more complicated)?","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"8c23024de933b1581678e2d592b03a8d5a9c035c","unresolved":false,"context_lines":[{"line_number":125,"context_line":"   ``keystone.conf`` files on all nodes, except the first one. Restart nodes"},{"line_number":126,"context_line":"   one at a time so that the new configuration can take effect."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"   When upgrading from Mitaka, which does not support ``[DEFAULT]"},{"line_number":129,"context_line":"   read_only_mode``, you can instead take away keystone\u0027s write permission to"},{"line_number":130,"context_line":"   the database. This will result in write operations failing with a less"},{"line_number":131,"context_line":"   graceful HTTP error ``500 Internal Server Error``. Consider creating an"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_df973c8e","line":128,"updated":"2016-08-04 14:59:20.000000000","message":"Won\u0027t this break for shadow users unless they create a newton specific DB account and is different from the one used in Mitaka?","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"e0623383c0f6e5c85d497ccb2cbe7e3aada7aee2","unresolved":false,"context_lines":[{"line_number":125,"context_line":"   ``keystone.conf`` files on all nodes, except the first one. Restart nodes"},{"line_number":126,"context_line":"   one at a time so that the new configuration can take effect."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"   When upgrading from Mitaka, which does not support ``[DEFAULT]"},{"line_number":129,"context_line":"   read_only_mode``, you can instead take away keystone\u0027s write permission to"},{"line_number":130,"context_line":"   the database. This will result in write operations failing with a less"},{"line_number":131,"context_line":"   graceful HTTP error ``500 Internal Server Error``. Consider creating an"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_d474289d","line":128,"in_reply_to":"bacf61ea_64e318da","updated":"2016-08-05 00:07:20.000000000","message":"Yes, auth for federation is what I was thinking, but now that I\u0027m thinking about it the PCI stuff would also have problems if enabled. Specifically recording auth attempts.","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"b42104b1f5d861f20275e134da3327022471a2dd","unresolved":false,"context_lines":[{"line_number":125,"context_line":"   ``keystone.conf`` files on all nodes, except the first one. Restart nodes"},{"line_number":126,"context_line":"   one at a time so that the new configuration can take effect."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"   When upgrading from Mitaka, which does not support ``[DEFAULT]"},{"line_number":129,"context_line":"   read_only_mode``, you can instead take away keystone\u0027s write permission to"},{"line_number":130,"context_line":"   the database. This will result in write operations failing with a less"},{"line_number":131,"context_line":"   graceful HTTP error ``500 Internal Server Error``. Consider creating an"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_64e318da","line":128,"in_reply_to":"bacf61ea_aa468178","updated":"2016-08-04 19:19:34.000000000","message":"This would mean that authentication for new federated users wouldn\u0027t be supported during an upgrade since it would require a write. This seems reasonable to me since we\u0027ve coupled user creation and user authentication in the shadow user implementation.","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"145e59ba69d85dfc6ca2a2b37794ef87bd8f975f","unresolved":false,"context_lines":[{"line_number":125,"context_line":"   ``keystone.conf`` files on all nodes, except the first one. Restart nodes"},{"line_number":126,"context_line":"   one at a time so that the new configuration can take effect."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"   When upgrading from Mitaka, which does not support ``[DEFAULT]"},{"line_number":129,"context_line":"   read_only_mode``, you can instead take away keystone\u0027s write permission to"},{"line_number":130,"context_line":"   the database. This will result in write operations failing with a less"},{"line_number":131,"context_line":"   graceful HTTP error ``500 Internal Server Error``. Consider creating an"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_35459a42","line":128,"in_reply_to":"bacf61ea_d474289d","updated":"2016-08-05 15:38:00.000000000","message":"Yes, so in the case of PCI, I think the best course of action would be to skip PCI-related writes while read-only mode is enabled. So, for example, if you have a maximum number of failed logins configured, and a user fails to authenticate, we simply don\u0027t increment the user\u0027s failed login counter in read-only mode.","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"a1725547c9c97e3bb137aae53f26dd55d216f855","unresolved":false,"context_lines":[{"line_number":125,"context_line":"   ``keystone.conf`` files on all nodes, except the first one. Restart nodes"},{"line_number":126,"context_line":"   one at a time so that the new configuration can take effect."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"   When upgrading from Mitaka, which does not support ``[DEFAULT]"},{"line_number":129,"context_line":"   read_only_mode``, you can instead take away keystone\u0027s write permission to"},{"line_number":130,"context_line":"   the database. This will result in write operations failing with a less"},{"line_number":131,"context_line":"   graceful HTTP error ``500 Internal Server Error``. Consider creating an"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_aa468178","line":128,"in_reply_to":"bacf61ea_df973c8e","updated":"2016-08-04 17:22:06.000000000","message":"Not sure I follow the question -- how is shadow users specifically related to this paragraph? Shadowing a new user requires a write operation, yes, but there\u0027d be nothing release specific about the operation.","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"b42104b1f5d861f20275e134da3327022471a2dd","unresolved":false,"context_lines":[{"line_number":143,"context_line":"   in the corresponding new schema."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"   At this point, the previous release may continue to read from the old schema"},{"line_number":146,"context_line":"   and but it is also available to be read in the new schema."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"#. Update your configuration files (``/etc/keystone/``) on all nodes (except"},{"line_number":149,"context_line":"   the first node, which you\u0027ve already done) with those corresponding to the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_c406441b","line":146,"updated":"2016-08-04 19:19:34.000000000","message":"nit: \n\n  At this point, the previous release may continue to read data from the old\n  schema, but the data is also available to be read by the new schema once\n  the migration is complete.\n\nThe \u0027it\u0027 in:\n\n  and but *it* is \n\nIs throwing me off only because it seems to imply the \u0027previous release\u0027 when I feel like we are talking about the data(?).","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"e0623383c0f6e5c85d497ccb2cbe7e3aada7aee2","unresolved":false,"context_lines":[{"line_number":143,"context_line":"   in the corresponding new schema."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"   At this point, the previous release may continue to read from the old schema"},{"line_number":146,"context_line":"   and but it is also available to be read in the new schema."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"#. Update your configuration files (``/etc/keystone/``) on all nodes (except"},{"line_number":149,"context_line":"   the first node, which you\u0027ve already done) with those corresponding to the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_f46facc1","line":146,"in_reply_to":"bacf61ea_c406441b","updated":"2016-08-05 00:07:20.000000000","message":"Having an \u0027and but\u0027 is never OK :-P","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"145e59ba69d85dfc6ca2a2b37794ef87bd8f975f","unresolved":false,"context_lines":[{"line_number":143,"context_line":"   in the corresponding new schema."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"   At this point, the previous release may continue to read from the old schema"},{"line_number":146,"context_line":"   and but it is also available to be read in the new schema."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"#. Update your configuration files (``/etc/keystone/``) on all nodes (except"},{"line_number":149,"context_line":"   the first node, which you\u0027ve already done) with those corresponding to the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_358aba64","line":146,"in_reply_to":"bacf61ea_f46facc1","updated":"2016-08-05 15:38:00.000000000","message":"So, I might prefer the and or but, yet, I\u0027ll fix it anyway.","commit_id":"2bbdd0ff55ef56126b33a122021cc27d23dc4f1d"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"821a6c2958bdb49d1b7e5f54365db8111837eacb","unresolved":false,"context_lines":[{"line_number":60,"context_line":""},{"line_number":61,"context_line":"#. Stop all keystone processes. Otherwise, you\u0027ll risk multiple releases of"},{"line_number":62,"context_line":"   keystone trying to write to the database at the same time, which may result"},{"line_number":63,"context_line":"   in data being inconsistently written and read."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"#. Make a backup of your database. Keystone does not support downgrading the"},{"line_number":66,"context_line":"   database, so restoring from a full backup is your only option for recovery"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_a50a3577","line":63,"range":{"start_line":63,"start_character":11,"end_line":63,"end_character":48},"updated":"2016-08-10 14:33:49.000000000","message":"nit: \"may result in data corruption\"","commit_id":"92495412630749154e0966d2bdec8dc4f6a500af"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"821a6c2958bdb49d1b7e5f54365db8111837eacb","unresolved":false,"context_lines":[{"line_number":83,"context_line":"--------------------------"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"This is a high-level description of our upgrade strategy built around"},{"line_number":86,"context_line":"``keystone-manage upgrade``. Although it is much more complex than the upgrade"},{"line_number":87,"context_line":"process described above, it assumes that you are not willing to have downtime"},{"line_number":88,"context_line":"of your control plane during the upgrade process. With this upgrade process,"},{"line_number":89,"context_line":"end users will still be able to authenticate to receive Fernet tokens (other"},{"line_number":90,"context_line":"token providers will experience an outage), and other OpenStack services will"},{"line_number":91,"context_line":"still be able to authenticate requests normally."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_c52489c6","line":88,"range":{"start_line":86,"start_character":29,"end_line":88,"end_character":49},"updated":"2016-08-10 14:33:49.000000000","message":"nit (suggestion): I think rather than \"much more complex\" requires additional steps.","commit_id":"92495412630749154e0966d2bdec8dc4f6a500af"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"821a6c2958bdb49d1b7e5f54365db8111837eacb","unresolved":false,"context_lines":[{"line_number":86,"context_line":"``keystone-manage upgrade``. Although it is much more complex than the upgrade"},{"line_number":87,"context_line":"process described above, it assumes that you are not willing to have downtime"},{"line_number":88,"context_line":"of your control plane during the upgrade process. With this upgrade process,"},{"line_number":89,"context_line":"end users will still be able to authenticate to receive Fernet tokens (other"},{"line_number":90,"context_line":"token providers will experience an outage), and other OpenStack services will"},{"line_number":91,"context_line":"still be able to authenticate requests normally."},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_09ea3bdb","line":89,"range":{"start_line":89,"start_character":56,"end_line":89,"end_character":69},"updated":"2016-08-10 14:33:49.000000000","message":"Maybe have a prerequisite section identifies the requirements for the upgrading without downtime process.","commit_id":"92495412630749154e0966d2bdec8dc4f6a500af"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"821a6c2958bdb49d1b7e5f54365db8111837eacb","unresolved":false,"context_lines":[{"line_number":90,"context_line":"token providers will experience an outage), and other OpenStack services will"},{"line_number":91,"context_line":"still be able to authenticate requests normally."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"However, in order to achieve zero downtime upgrades, keystone\u0027s API"},{"line_number":94,"context_line":"capabilities *are* limited for the duration of the upgrade, resulting in a"},{"line_number":95,"context_line":"partial service outage. API operations which require write access to the"},{"line_number":96,"context_line":"database, such as creating users, changing passwords, and managing role"},{"line_number":97,"context_line":"assignments will fail with HTTP error ``503 Service Unavailable`` for a portion"},{"line_number":98,"context_line":"of the upgrade process."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"#. Make a backup of your database. Keystone does not support downgrading the"},{"line_number":101,"context_line":"   database, so restoring from a full backup is your only option for recovery"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_a985ef07","line":98,"range":{"start_line":93,"start_character":0,"end_line":98,"end_character":23},"updated":"2016-08-10 14:33:49.000000000","message":"This paragraph feels like an overview description that could be at the beginning of the process.","commit_id":"92495412630749154e0966d2bdec8dc4f6a500af"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"821a6c2958bdb49d1b7e5f54365db8111837eacb","unresolved":false,"context_lines":[{"line_number":102,"context_line":"   in the event of an upgrade failure."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"#. Stop the keystone processes on the first node (or really, any arbitrary"},{"line_number":105,"context_line":"   node). This node will serve to orchestrate database upgrades."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"#. Upgrade your first node to the next release, but do not start any keystone"},{"line_number":108,"context_line":"   processes."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_a99ccf5d","line":105,"range":{"start_line":105,"start_character":10,"end_line":105,"end_character":64},"updated":"2016-08-10 14:33:49.000000000","message":"Nice!","commit_id":"92495412630749154e0966d2bdec8dc4f6a500af"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"821a6c2958bdb49d1b7e5f54365db8111837eacb","unresolved":false,"context_lines":[{"line_number":110,"context_line":"#. Update your configuration files on the first node (``/etc/keystone/``) with"},{"line_number":111,"context_line":"   those corresponding to the latest release."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"#. (*New in Newton*) Run ``keystone-manage doctor`` on the first node to"},{"line_number":114,"context_line":"   diagnose symptoms of common deployment issues and receive instructions for"},{"line_number":115,"context_line":"   resolving them."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"#. Run ``keystone-manage upgrade --expand`` on the first node to expand the"},{"line_number":118,"context_line":"   database schema to a superset of what both the previous and next release can"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_09299be6","line":115,"range":{"start_line":113,"start_character":21,"end_line":115,"end_character":18},"updated":"2016-08-10 14:33:49.000000000","message":"nit: Run ``keystone-manage doctor`` and resolve any issues identified based on the instructions received.","commit_id":"92495412630749154e0966d2bdec8dc4f6a500af"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"821a6c2958bdb49d1b7e5f54365db8111837eacb","unresolved":false,"context_lines":[{"line_number":126,"context_line":"   ``keystone.conf`` files on all nodes, except the first one. Restart nodes"},{"line_number":127,"context_line":"   one at a time so that the new configuration can take effect."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"   When upgrading from Mitaka, which does not support ``[DEFAULT]"},{"line_number":130,"context_line":"   read_only_mode``, you can instead take away keystone\u0027s write permission to"},{"line_number":131,"context_line":"   the database. This will result in write operations failing with a less"},{"line_number":132,"context_line":"   graceful HTTP error ``500 Internal Server Error``. Consider creating an"},{"line_number":133,"context_line":"   alternate, read-only database user to use in keystone\u0027s ``[database]"},{"line_number":134,"context_line":"   connection`` string instead of the ``[DEFAULT] read_only_mode`` option."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"   At this point, keystone\u0027s API capabilities are limited, and no write"},{"line_number":137,"context_line":"   operations are going to the database."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_a9d4cfbc","line":134,"range":{"start_line":129,"start_character":3,"end_line":134,"end_character":74},"updated":"2016-08-10 14:33:49.000000000","message":"Do we need this?  Why not just start from Newton?","commit_id":"92495412630749154e0966d2bdec8dc4f6a500af"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"821a6c2958bdb49d1b7e5f54365db8111837eacb","unresolved":false,"context_lines":[{"line_number":139,"context_line":"#. Run ``keystone-manage upgrade --migrate`` on the first node to perform data"},{"line_number":140,"context_line":"   migrations."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"   Without read-only mode in effect, the service might be racing the data"},{"line_number":143,"context_line":"   migration process to create data in the old schema without also creating it"},{"line_number":144,"context_line":"   in the corresponding new schema."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"   At this point, the previous release may continue to read from the old schema"},{"line_number":147,"context_line":"   and it is also available to be read in the new schema."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_c99dc30b","line":144,"range":{"start_line":142,"start_character":3,"end_line":144,"end_character":35},"updated":"2016-08-10 14:33:49.000000000","message":"I don\u0027t think this is needed from an operations instruction perspective.","commit_id":"92495412630749154e0966d2bdec8dc4f6a500af"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"7962bedb50f0b71d1d0cc89e8865a6f9e72ba5ac","unresolved":false,"context_lines":[{"line_number":20,"context_line":"upgrading across releases. The traditional approach requires a significant"},{"line_number":21,"context_line":"outage to be scheduled for the entire duration of the upgrade process. The more"},{"line_number":22,"context_line":"modern approach results in zero downtime, but is more complicated due to a"},{"line_number":23,"context_line":"longer upgrade procedure and limits the available capabilities of the service"},{"line_number":24,"context_line":"during a portion of the process."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":".. NOTE::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9ad45d7e_e529889c","line":23,"updated":"2016-08-11 15:29:44.000000000","message":"+1 but I actually need to revise this further, because the available capabilities are NOT limited by the process described in this patchset (this applied to previous patchsets.","commit_id":"93feef2da3a73464b48cbc52c18d0cfc62f788e8"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"7962bedb50f0b71d1d0cc89e8865a6f9e72ba5ac","unresolved":false,"context_lines":[{"line_number":111,"context_line":"   utilize, and create triggers to facilitate the live migration process."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"   At this point, new columns and tables may exist in the database, but will"},{"line_number":114,"context_line":"   now all be populated in such a way that the next release will be able to"},{"line_number":115,"context_line":"   function normally."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"   As the previous release continues to write to the old schema, database"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9ad45d7e_a52310bc","line":114,"updated":"2016-08-11 15:29:44.000000000","message":"This was correct before - the columns may be empty, populated by triggers, or defaulted to some other useless value, and thus \"not all populated...\"","commit_id":"93feef2da3a73464b48cbc52c18d0cfc62f788e8"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"a3bf9809eed0568a3848abd7ce79be54cca01f07","unresolved":false,"context_lines":[{"line_number":19,"context_line":"As of the Newton release, keystone supports two different approaches to"},{"line_number":20,"context_line":"upgrading across releases. The traditional approach requires a significant"},{"line_number":21,"context_line":"outage to be scheduled for the entire duration of the upgrade process. The more"},{"line_number":22,"context_line":"modern approach results in zero downtime, but is more complicated due to a"},{"line_number":23,"context_line":"longer upgrade procedure."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":".. NOTE::"},{"line_number":26,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_4e050c0f","line":23,"range":{"start_line":22,"start_character":42,"end_line":23,"end_character":25},"updated":"2016-08-11 17:19:28.000000000","message":"nit: I think you could just say \"however, requires additional steps.\"  The process to me is not more complex, you\u0027re essentially running a couple extra commands and have a longer procedure.","commit_id":"4af85b57ba222b022733e1e2b2f32f83579a5373"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"a3bf9809eed0568a3848abd7ce79be54cca01f07","unresolved":false,"context_lines":[{"line_number":82,"context_line":"--------------------------"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"This is a high-level description of our upgrade strategy built around"},{"line_number":85,"context_line":"``keystone-manage upgrade``. Although it is much more complex than the upgrade"},{"line_number":86,"context_line":"process described above, it assumes that you are not willing to have downtime"},{"line_number":87,"context_line":"of your control plane during the upgrade process. With this upgrade process,"},{"line_number":88,"context_line":"end users will still be able to authenticate to receive tokens normally, and"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_6e857058","line":85,"range":{"start_line":85,"start_character":29,"end_line":85,"end_character":61},"updated":"2016-08-11 17:19:28.000000000","message":"nit (suggestion): \"This approach assumes... and will require additional work.","commit_id":"4af85b57ba222b022733e1e2b2f32f83579a5373"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"b014b0c7e0e0c22e15dde8af155596e48e2a3ff7","unresolved":false,"context_lines":[{"line_number":82,"context_line":"--------------------------"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"This is a high-level description of our upgrade strategy built around"},{"line_number":85,"context_line":"``keystone-manage upgrade``. Although it is much more complex than the upgrade"},{"line_number":86,"context_line":"process described above, it assumes that you are not willing to have downtime"},{"line_number":87,"context_line":"of your control plane during the upgrade process. With this upgrade process,"},{"line_number":88,"context_line":"end users will still be able to authenticate to receive tokens normally, and"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7ac969e8_c95c35f0","line":85,"range":{"start_line":85,"start_character":44,"end_line":85,"end_character":53},"updated":"2016-08-12 21:26:01.000000000","message":"s/much more/more","commit_id":"4af85b57ba222b022733e1e2b2f32f83579a5373"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"a3bf9809eed0568a3848abd7ce79be54cca01f07","unresolved":false,"context_lines":[{"line_number":141,"context_line":"   data migration triggers."},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"   When this process completes, the database will no longer be able to support"},{"line_number":144,"context_line":"   the previous release."}],"source_content_type":"text/x-rst","patch_set":5,"id":"9ad45d7e_aeaac882","line":144,"range":{"start_line":144,"start_character":3,"end_line":144,"end_character":24},"updated":"2016-08-11 17:19:28.000000000","message":"nit: The upgrade process is not complete; continue with validation testing... (or something like that).","commit_id":"4af85b57ba222b022733e1e2b2f32f83579a5373"},{"author":{"_account_id":17860,"name":"Samuel de Medeiros Queiroz","email":"samueldmq@gmail.com","username":"samueldmq"},"change_message_id":"f625f034aba71ead3098ee4371654dfd7f82d9e0","unresolved":false,"context_lines":[{"line_number":70,"context_line":"#. Update your configuration files (``/etc/keystone/``) with those"},{"line_number":71,"context_line":"   corresponding from the latest release."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"#. Run ``keystone-manage db_sync`` from any single node to upgrade both the"},{"line_number":74,"context_line":"   database schema and run any corresponding database migrations."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"#. (*New in Newton*) Run ``keystone-manage doctor`` to diagnose symptoms of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3ac371cc_13d95684","line":73,"range":{"start_line":73,"start_character":40,"end_line":73,"end_character":43},"updated":"2016-08-18 19:58:32.000000000","message":"every?","commit_id":"a5e2906dc4134fd0505d5fbf93b3aba879e133d3"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"4573509895e83ae90ecfd55e20ddb78ad8529ad3","unresolved":false,"context_lines":[{"line_number":70,"context_line":"#. Update your configuration files (``/etc/keystone/``) with those"},{"line_number":71,"context_line":"   corresponding from the latest release."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"#. Run ``keystone-manage db_sync`` from any single node to upgrade both the"},{"line_number":74,"context_line":"   database schema and run any corresponding database migrations."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"#. (*New in Newton*) Run ``keystone-manage doctor`` to diagnose symptoms of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1ac06dbe_0a055679","line":73,"range":{"start_line":73,"start_character":40,"end_line":73,"end_character":43},"in_reply_to":"3ac371cc_13d95684","updated":"2016-08-21 16:53:23.000000000","message":"no, just one.","commit_id":"a5e2906dc4134fd0505d5fbf93b3aba879e133d3"},{"author":{"_account_id":19554,"name":"Nam","email":"namnh68@fsoft.com.vn","username":"namnh"},"change_message_id":"2e3a86c02e6bdac44d7e6b4245bbe7a6d4c46acd","unresolved":false,"context_lines":[{"line_number":130,"context_line":"   the first node, which you\u0027ve already done) with those corresponding to the"},{"line_number":131,"context_line":"   latest release."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"#. Upgrade all keystone nodes to the next release, and restart them one at a"},{"line_number":134,"context_line":"   time. During this step, you\u0027ll have a mix of releases operating side by"},{"line_number":135,"context_line":"   side, both writing to the database."},{"line_number":136,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"1a95cdbc_81523edc","line":133,"range":{"start_line":133,"start_character":51,"end_line":133,"end_character":76},"updated":"2016-10-04 14:26:58.000000000","message":"Hi everyone in this patch.\n\nCould I discuss this topic again. I think we will have downtime if we do at this step. I think we should say that \"start service on first node. Then we upgrade all remain keystone nodes\" to ensure that we will not downtime during upgrading. Actually, I tried modify this step as above, it seems success but it had a bug as my colleague reported. [1]. How do you think about this?\n\n[1] https://bugs.launchpad.net/keystone/+bug/1630259","commit_id":"a5e2906dc4134fd0505d5fbf93b3aba879e133d3"}]}