)]}'
{"specs/keystone/newton/manage-migration.rst":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"bc82e95b85a16af59116e4b66af6d5e9700bc2eb","unresolved":false,"context_lines":[{"line_number":105,"context_line":"   not migrate any data."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"2. Restart the remaining nodes running the X release in read-only mode to"},{"line_number":108,"context_line":"   prevent any combination of X and X+1 nodes from writing to the database as"},{"line_number":109,"context_line":"   the same time."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"3. On the X+1 node, run ``\u003cservice\u003e-manage db_sync --migrate`` to migrate data"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bacf61ea_f8fc8fb6","line":108,"updated":"2016-08-05 19:53:13.000000000","message":"at*","commit_id":"9219144da4d9c87341015f480e6fd130da8ddb0f"},{"author":{"_account_id":13063,"name":"WEI CHEN","email":"dave.jungler@gmail.com","username":"wei.d.chen"},"change_message_id":"0964f36aa1fed1134052a902514211fcdd6a5130","unresolved":false,"context_lines":[{"line_number":72,"context_line":""},{"line_number":73,"context_line":"In the mean time, we can have a compromise by preventing writes to the database"},{"line_number":74,"context_line":"during certain parts of the upgrade process. More specifically, by blocking any"},{"line_number":75,"context_line":"keystone process from writing to the database while we there is a mix of"},{"line_number":76,"context_line":"releases running and data is migrated to the new schema, we eliminate:"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"1. The need to have the next release understand the previous release\u0027s data"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bacf61ea_f5fe3168","line":75,"range":{"start_line":75,"start_character":51,"end_line":75,"end_character":55},"updated":"2016-08-08 07:45:01.000000000","message":"/d \u0027we\u0027","commit_id":"6c79af269616b51537352d4534ce6e5571f62565"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"734b35364f06dbf4b21eb3ee31d87409aeb5dd48","unresolved":false,"context_lines":[{"line_number":72,"context_line":""},{"line_number":73,"context_line":"In the mean time, we can have a compromise by preventing writes to the database"},{"line_number":74,"context_line":"during certain parts of the upgrade process. More specifically, by blocking any"},{"line_number":75,"context_line":"keystone process from writing to the database while we there is a mix of"},{"line_number":76,"context_line":"releases running and data is migrated to the new schema, we eliminate:"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"1. The need to have the next release understand the previous release\u0027s data"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_25dd1b15","line":75,"in_reply_to":"bacf61ea_f5fe3168","updated":"2016-08-08 16:15:08.000000000","message":"Done","commit_id":"6c79af269616b51537352d4534ce6e5571f62565"},{"author":{"_account_id":13063,"name":"WEI CHEN","email":"dave.jungler@gmail.com","username":"wei.d.chen"},"change_message_id":"0964f36aa1fed1134052a902514211fcdd6a5130","unresolved":false,"context_lines":[{"line_number":111,"context_line":"3. On the X+1 node, run ``\u003cservice\u003e-manage db_sync --migrate`` to migrate data"},{"line_number":112,"context_line":"   from the old schema to the new schema."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"4. Upgrade and restart all remaining nodes to the X+1 release one at a time."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"5. Restart all nodes without read-only mode to resume write operations."},{"line_number":117,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"bacf61ea_383720e4","line":114,"range":{"start_line":114,"start_character":15,"end_line":114,"end_character":22},"updated":"2016-08-08 07:45:01.000000000","message":"we don\u0027t need restart at this step, this is only needed after the code has been upgraded, restart will be done in step5.","commit_id":"6c79af269616b51537352d4534ce6e5571f62565"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"734b35364f06dbf4b21eb3ee31d87409aeb5dd48","unresolved":false,"context_lines":[{"line_number":111,"context_line":"3. On the X+1 node, run ``\u003cservice\u003e-manage db_sync --migrate`` to migrate data"},{"line_number":112,"context_line":"   from the old schema to the new schema."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"4. Upgrade and restart all remaining nodes to the X+1 release one at a time."},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"5. Restart all nodes without read-only mode to resume write operations."},{"line_number":117,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_25607b35","line":114,"in_reply_to":"bacf61ea_383720e4","updated":"2016-08-08 16:15:08.000000000","message":"This actually does need to be done in two steps, but I\u0027ll amend the description to explain why. In short, you need all nodes running the latest release before you can safely resume writing.","commit_id":"6c79af269616b51537352d4534ce6e5571f62565"},{"author":{"_account_id":13063,"name":"WEI CHEN","email":"dave.jungler@gmail.com","username":"wei.d.chen"},"change_message_id":"0964f36aa1fed1134052a902514211fcdd6a5130","unresolved":false,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"- ``keystone-manage db_sync --migrate``: Will perform on-the-fly data"},{"line_number":134,"context_line":"  migrations from old schema to new schema, while the database is protected"},{"line_number":135,"context_line":"  from write operations and all nodes are running the X release."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"  Additionally, if this process is guaranteed to be idempotent, we can minimize"},{"line_number":138,"context_line":"  the amount of time that deployers would need to use read-only mode by"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bacf61ea_988e0c77","line":135,"range":{"start_line":135,"start_character":27,"end_line":135,"end_character":37},"updated":"2016-08-08 07:45:01.000000000","message":"This is not consistent with the step 3 mentioned above, one node has been upgraded.","commit_id":"6c79af269616b51537352d4534ce6e5571f62565"},{"author":{"_account_id":4,"name":"Dolph Mathews","email":"dolph.mathews@gmail.com","username":"dolph"},"change_message_id":"734b35364f06dbf4b21eb3ee31d87409aeb5dd48","unresolved":false,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"- ``keystone-manage db_sync --migrate``: Will perform on-the-fly data"},{"line_number":134,"context_line":"  migrations from old schema to new schema, while the database is protected"},{"line_number":135,"context_line":"  from write operations and all nodes are running the X release."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"  Additionally, if this process is guaranteed to be idempotent, we can minimize"},{"line_number":138,"context_line":"  the amount of time that deployers would need to use read-only mode by"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ad45d7e_25bcfb6b","line":135,"in_reply_to":"bacf61ea_988e0c77","updated":"2016-08-08 16:15:08.000000000","message":"The catch is that the node which has been upgraded to the X+1 release is not actually running (it\u0027s not serving requests). Will amend with clarification.","commit_id":"6c79af269616b51537352d4534ce6e5571f62565"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"d3753d49b686484661fa13429403c291b397a877","unresolved":false,"context_lines":[{"line_number":83,"context_line":"2. The need for any clean up operations beyond a one-time data migration during"},{"line_number":84,"context_line":"   the read-only period."},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"3. The need for the application to discover the state of the schema at runtime"},{"line_number":87,"context_line":"   (a requirement which presents numerous possible race conditions)."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Proposed Change"},{"line_number":90,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9ad45d7e_7b6a101c","line":87,"range":{"start_line":86,"start_character":3,"end_line":87,"end_character":66},"updated":"2016-08-08 16:59:19.000000000","message":"I believe those race conditions are covered by the existing spec, at the expense of having more commands in the sequence","commit_id":"1c94550d9eb13dc5fa693386f85b591ebb24cdb1"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"b0246466f43a83e74b3cdfa1690297e27d543ffb","unresolved":false,"context_lines":[{"line_number":104,"context_line":"   --expand`` command is run which creates new database structures, but does"},{"line_number":105,"context_line":"   not migrate any data."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"2. Restart the remaining nodes running the X release in read-only mode to"},{"line_number":108,"context_line":"   prevent any combination of X and X+1 nodes from writing to the database at"},{"line_number":109,"context_line":"   the same time."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"3. On the X+1 node, run ``\u003cservice\u003e-manage db_sync --migrate`` to migrate data"},{"line_number":112,"context_line":"   from the old schema to the new schema."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9ad45d7e_cf736c4c","line":109,"range":{"start_line":107,"start_character":3,"end_line":109,"end_character":17},"updated":"2016-08-08 22:24:17.000000000","message":"How is this RO mode enforced? Is it code in X that reads the config flag and prevents writes? If so, doesn\u0027t this mean that this solution could not support rolling upgrades between Mitaka and Newton, since Mitaka is X in this case, and Mitaka doesn\u0027t understand the RO flag.","commit_id":"1c94550d9eb13dc5fa693386f85b591ebb24cdb1"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"06e6460e61ee88692671a562fe4155e19ab34e07","unresolved":false,"context_lines":[{"line_number":108,"context_line":"   prevent any combination of X and X+1 nodes from writing to the database at"},{"line_number":109,"context_line":"   the same time."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"3. On the X+1 node, run ``\u003cservice\u003e-manage db_sync --migrate`` to migrate data"},{"line_number":112,"context_line":"   from the old schema to the new schema."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"4. Upgrade and restart all remaining nodes to the X+1 release one at a time,"},{"line_number":115,"context_line":"   preserving read-only mode."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"5. Once all nodes are running the X+1 release, it is safe to disable read-only"},{"line_number":118,"context_line":"   mode and resume write operations. Disable read-only mode and apply the new"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9ad45d7e_f864464a","line":115,"range":{"start_line":111,"start_character":3,"end_line":115,"end_character":29},"updated":"2016-08-08 16:35:41.000000000","message":"so while we are in RO mode, would the implication be that nobody using UUID tokens could authenticate? (since doesn\u0027t that write to the DB?)","commit_id":"1c94550d9eb13dc5fa693386f85b591ebb24cdb1"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"d3753d49b686484661fa13429403c291b397a877","unresolved":false,"context_lines":[{"line_number":115,"context_line":"   preserving read-only mode."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"5. Once all nodes are running the X+1 release, it is safe to disable read-only"},{"line_number":118,"context_line":"   mode and resume write operations. Disable read-only mode and apply the new"},{"line_number":119,"context_line":"   behavior with a rolling restart."},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"4. Once all the nodes are upgraded and writing to the new schema, remove the"},{"line_number":122,"context_line":"   old schema using ``\u003cservice\u003e-manage db_sync --contract``."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9ad45d7e_56a56302","line":119,"range":{"start_line":118,"start_character":37,"end_line":119,"end_character":35},"updated":"2016-08-08 16:59:19.000000000","message":"minor point is that obviously it is possible for APIs to behave differently until all nodes are restarted, since depending on which node they:\n- may or may not be able to write\n- may get a different answer to a read (since reading from a new node could see newly written data that came from a restarted node, while reading from an old node would get old data)\n\nI\u0027m not sure if this is too much of an issue, but something to be aware of","commit_id":"1c94550d9eb13dc5fa693386f85b591ebb24cdb1"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"d3753d49b686484661fa13429403c291b397a877","unresolved":false,"context_lines":[{"line_number":124,"context_line":"For keystone in this release, it is proposed that we support all the above"},{"line_number":125,"context_line":"commands and read-only mode :"},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"- ``[DEFAULT] read_only_mode``: A boolean configuration option in"},{"line_number":128,"context_line":"  ``keystone.conf`` which tells keystone whether or not it\u0027s allowed to write"},{"line_number":129,"context_line":"  to the database."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"- ``keystone-manage db_sync --expand``: Expands the database schema by"},{"line_number":132,"context_line":"  performing purely \"additive\" operations such as creating new columns,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9ad45d7e_dbe5fca8","line":129,"range":{"start_line":127,"start_character":2,"end_line":129,"end_character":18},"updated":"2016-08-08 16:59:19.000000000","message":"so if install a keystone OOTB (no upgrades or anything), it is RO mode until I change it?","commit_id":"1c94550d9eb13dc5fa693386f85b591ebb24cdb1"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"a681aaf2bf0d0e0c1d7954f245308405e5734aae","unresolved":false,"context_lines":[{"line_number":124,"context_line":"For keystone in this release, it is proposed that we support all the above"},{"line_number":125,"context_line":"commands and read-only mode :"},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"- ``[DEFAULT] read_only_mode``: A boolean configuration option in"},{"line_number":128,"context_line":"  ``keystone.conf`` which tells keystone whether or not it\u0027s allowed to write"},{"line_number":129,"context_line":"  to the database."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"- ``keystone-manage db_sync --expand``: Expands the database schema by"},{"line_number":132,"context_line":"  performing purely \"additive\" operations such as creating new columns,"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9ad45d7e_4ce794e4","line":129,"range":{"start_line":127,"start_character":2,"end_line":129,"end_character":18},"in_reply_to":"9ad45d7e_dbe5fca8","updated":"2016-08-08 17:58:15.000000000","message":"So you could use a database flag here rather than a config setting, with the database flag being set by a --set-readonly command and unset by the complete of the --migrate command . This would avoid a default RO mode.","commit_id":"1c94550d9eb13dc5fa693386f85b591ebb24cdb1"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"d3753d49b686484661fa13429403c291b397a877","unresolved":false,"context_lines":[{"line_number":131,"context_line":"- ``keystone-manage db_sync --expand``: Expands the database schema by"},{"line_number":132,"context_line":"  performing purely \"additive\" operations such as creating new columns,"},{"line_number":133,"context_line":"  indexes, and tables. This can be run while all nodes are still on the X"},{"line_number":134,"context_line":"  release."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"- ``keystone-manage db_sync --migrate``: Will perform on-the-fly data"},{"line_number":137,"context_line":"  migrations from old schema to new schema, while the database is protected"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9ad45d7e_bb9008ee","line":134,"range":{"start_line":134,"start_character":9,"end_line":134,"end_character":10},"updated":"2016-08-08 16:59:19.000000000","message":"...and all can still write to the DB I assume?","commit_id":"1c94550d9eb13dc5fa693386f85b591ebb24cdb1"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"06e6460e61ee88692671a562fe4155e19ab34e07","unresolved":false,"context_lines":[{"line_number":133,"context_line":"  indexes, and tables. This can be run while all nodes are still on the X"},{"line_number":134,"context_line":"  release."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"- ``keystone-manage db_sync --migrate``: Will perform on-the-fly data"},{"line_number":137,"context_line":"  migrations from old schema to new schema, while the database is protected"},{"line_number":138,"context_line":"  from write operations and all nodes serving requests are still running the X"},{"line_number":139,"context_line":"  release."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9ad45d7e_788696ba","line":136,"range":{"start_line":136,"start_character":5,"end_line":136,"end_character":37},"updated":"2016-08-08 16:35:41.000000000","message":"so this stage is the equivalent of the versioned object on-the-fly stuff, I assume?","commit_id":"1c94550d9eb13dc5fa693386f85b591ebb24cdb1"},{"author":{"_account_id":6482,"name":"Steve Martinelli","email":"s.martinelli@gmail.com","username":"stevemar"},"change_message_id":"551de8fc0984aaa297b65b182d745846553ba868","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"`bp manage-migration \u003chttps://blueprints.launchpad.net/keystone/+spec/manage-migration\u003e`_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Provide a rolling upgrade steps in ``keystone-manage`` to allow for zero"},{"line_number":14,"context_line":"downtime database upgrades."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3ac371cc_301d5d10","line":13,"range":{"start_line":13,"start_character":8,"end_line":13,"end_character":9},"updated":"2016-08-15 15:13:54.000000000","message":"remove \"a\"","commit_id":"84a5147010e9a62c741437fe3c19472b2a632d14"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"9034864e8f9705fda4c05429e5d6c9b06c3c6fb4","unresolved":false,"context_lines":[{"line_number":13,"context_line":"Provide a rolling upgrade steps in ``keystone-manage`` to allow for zero"},{"line_number":14,"context_line":"downtime database upgrades."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"OpenStack services are moving towards support for rolling upgrades, with"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9ad45d7e_f3a669ac","line":16,"range":{"start_line":16,"start_character":0,"end_line":16,"end_character":19},"updated":"2016-08-11 17:07:20.000000000","message":"The problem description in general is a little wordy; difficult to follow.","commit_id":"84a5147010e9a62c741437fe3c19472b2a632d14"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"9034864e8f9705fda4c05429e5d6c9b06c3c6fb4","unresolved":false,"context_lines":[{"line_number":37,"context_line":"support for rolling upgrades by only allowing additive changes to the database"},{"line_number":38,"context_line":"(this is protected via tests)."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"To support just the rolling upgrade part, keystone would allow (given we have"},{"line_number":41,"context_line":"only permitted additive database changes) the following sequence:"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"1. Take a keystone out of service and replace keystone with the new version,"},{"line_number":44,"context_line":"   but don\u0027t run it yet. Execute the keystone-manage commands to upgrade the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9ad45d7e_33be41ff","line":41,"range":{"start_line":40,"start_character":64,"end_line":41,"end_character":40},"updated":"2016-08-11 17:07:20.000000000","message":"Do we still need this?","commit_id":"84a5147010e9a62c741437fe3c19472b2a632d14"},{"author":{"_account_id":18338,"name":"Ron De Rose","email":"ronald.de.rose@intel.com","username":"derosenet"},"change_message_id":"9034864e8f9705fda4c05429e5d6c9b06c3c6fb4","unresolved":false,"context_lines":[{"line_number":80,"context_line":""},{"line_number":81,"context_line":"This approach allows us to eliminate:"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"1. The need to have the next release understand the previous release\u0027s schema"},{"line_number":84,"context_line":"   (which would put a complex maintenance burden on developers, substantially"},{"line_number":85,"context_line":"   raises the barrier to entry for new developers, and presents a risk of"},{"line_number":86,"context_line":"   relatively subtle bugs)."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"2. The need for any clean up operations beyond a one-time data migration."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"3. The need for the application to discover the state of the schema at runtime"},{"line_number":91,"context_line":"   (a requirement which presents numerous possible race conditions)."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Proposed Change"},{"line_number":94,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9ad45d7e_d3cc058b","line":91,"range":{"start_line":83,"start_character":0,"end_line":91,"end_character":68},"updated":"2016-08-11 17:07:20.000000000","message":"++","commit_id":"84a5147010e9a62c741437fe3c19472b2a632d14"},{"author":{"_account_id":5707,"name":"Henry Nash","email":"henryn@linux.vnet.ibm.com","username":"henry-nash"},"change_message_id":"e8f57c10971eedb90476ff15f0e69b4c267d9891","unresolved":false,"context_lines":[{"line_number":151,"context_line":"attempts at the next release are possible."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"In terms of implementation, the ``keystone-manage db_sync --expand``,"},{"line_number":154,"context_line":"``keystone-manage db_sync --migrate`` and ``keystone-manage db_sync"},{"line_number":155,"context_line":"--contract`` phases will be driven by ``sqlalchemy-migrate`` repositories."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"The proposed approach is designed to support both deployers who are upgrading"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7ac969e8_a9a0d9a6","line":154,"range":{"start_line":154,"start_character":2,"end_line":154,"end_character":35},"updated":"2016-08-12 21:27:53.000000000","message":"I\u0027m not sure the migrate cycle should be a versioned repo...since you might need to execute it multiple times (e.g. for batching)...","commit_id":"84a5147010e9a62c741437fe3c19472b2a632d14"}]}