)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"425cae10b4e8c2040afd65b629e6fcfacba832d0","unresolved":false,"context_lines":[{"line_number":17,"context_line":"version mangement via the migration script in `tools/*-migrate-db.sh`,"},{"line_number":18,"context_line":"this patch provides a way to stamp the current version via the CLI:"},{"line_number":19,"context_line":"`placement-manage db stamp \u003cversion\u003e`."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Change-Id: I65fa8fd6e2479224f1b25cd62ca15a90d5948424"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"3f79a3b5_ad1ba36b","line":20,"updated":"2018-11-27 10:08:34.000000000","message":"As far as I see stamping is only needed for the case when we migrate the tables from nova to placement. This is done with a separate *-migrate-db.sh script. Can we somehow limit the possibility and usage of stamping to those migration scripts?\n\nI mean if the placement-manage allows stamping blindly that makes the stamp command pretty dangerous.","commit_id":"fe30a44e9d61c83c55446c2665b811c77ffe565d"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"2480ed72418aef49019dc0e1cd1cdd2a643f479a","unresolved":false,"context_lines":[{"line_number":17,"context_line":"version mangement via the migration script in `tools/*-migrate-db.sh`,"},{"line_number":18,"context_line":"this patch provides a way to stamp the current version via the CLI:"},{"line_number":19,"context_line":"`placement-manage db stamp \u003cversion\u003e`."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Change-Id: I65fa8fd6e2479224f1b25cd62ca15a90d5948424"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"3f79a3b5_4d9d2f56","line":20,"in_reply_to":"3f79a3b5_ad1ba36b","updated":"2018-11-27 10:25:11.000000000","message":"People may do the migration using other tools so there needs to be a separate command to say \"accept this migrated database into alembic\". We could change the stamp command to a different name that takes no args, but under the covers stamps to b4ed3a175331\n\nBut we still the command to be usable by other tooling.\n\nAlso, keep in mind that the alembic command line tool exposes stamp as well so even if we obscure the power to stamp arbitrarily the power will always be there. Including people changing the alembic_version table.","commit_id":"fe30a44e9d61c83c55446c2665b811c77ffe565d"}],"doc/source/cli/placement-manage.rst":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"ca572c319c9fc527a32dc956bb124f8735b0cb16","unresolved":false,"context_lines":[{"line_number":67,"context_line":"    is not set, the command will fail. The defined database must already exist."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"``placement-manage db stamp \u003cversion\u003e``"},{"line_number":70,"context_line":"    Stamp the revision table with the given revision; don’t run any migrations."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_92a84274","line":70,"updated":"2018-11-27 09:47:23.000000000","message":"Is it worth explaining why/when you might want to do this (when the database already exists and you want to bring it under alembic control).","commit_id":"fe30a44e9d61c83c55446c2665b811c77ffe565d"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"76dd9c8794c430f47c03e214262002ed3f4f2197","unresolved":false,"context_lines":[{"line_number":67,"context_line":"    is not set, the command will fail. The defined database must already exist."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"``placement-manage db stamp \u003cversion\u003e``"},{"line_number":70,"context_line":"    Stamp the revision table with the given revision; don’t run any migrations."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_33aa90cf","line":70,"in_reply_to":"3f79a3b5_92a84274","updated":"2018-11-27 12:12:00.000000000","message":"Yes it is, IMO. Done.","commit_id":"fe30a44e9d61c83c55446c2665b811c77ffe565d"}],"doc/source/index.rst":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"ca572c319c9fc527a32dc956bb124f8735b0cb16","unresolved":false,"context_lines":[{"line_number":169,"context_line":"Note that after you migrate the tables, you should stamp the version explicitly"},{"line_number":170,"context_line":"via the ``placement-manage db stamp b4ed3a175331`` command. Otherwise, syncing"},{"line_number":171,"context_line":"the database version fails because it tries to create migrated tables again on"},{"line_number":172,"context_line":"the initial version upgrade: (initial) -\u003e (b4ed3a175331)."},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"**3. Create accounts and update the service catalog**"},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d200fa6b","line":172,"updated":"2018-11-27 09:47:23.000000000","message":"If we require that people do this, should the script do it for them? I\u0027m not sure.","commit_id":"fe30a44e9d61c83c55446c2665b811c77ffe565d"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"76dd9c8794c430f47c03e214262002ed3f4f2197","unresolved":false,"context_lines":[{"line_number":169,"context_line":"Note that after you migrate the tables, you should stamp the version explicitly"},{"line_number":170,"context_line":"via the ``placement-manage db stamp b4ed3a175331`` command. Otherwise, syncing"},{"line_number":171,"context_line":"the database version fails because it tries to create migrated tables again on"},{"line_number":172,"context_line":"the initial version upgrade: (initial) -\u003e (b4ed3a175331)."},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"**3. Create accounts and update the service catalog**"},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_b35300dd","line":172,"in_reply_to":"3f79a3b5_0d5ad71d","updated":"2018-11-27 12:12:00.000000000","message":"Not sure if we should, but we\u0027d like to do this by script if possible. https://review.openstack.org/#/c/604454/22 comes first to my mind. But I guess this is not where `placement-manage` command becomes available.","commit_id":"fe30a44e9d61c83c55446c2665b811c77ffe565d"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"425cae10b4e8c2040afd65b629e6fcfacba832d0","unresolved":false,"context_lines":[{"line_number":169,"context_line":"Note that after you migrate the tables, you should stamp the version explicitly"},{"line_number":170,"context_line":"via the ``placement-manage db stamp b4ed3a175331`` command. Otherwise, syncing"},{"line_number":171,"context_line":"the database version fails because it tries to create migrated tables again on"},{"line_number":172,"context_line":"the initial version upgrade: (initial) -\u003e (b4ed3a175331)."},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"**3. Create accounts and update the service catalog**"},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_0d5ad71d","line":172,"in_reply_to":"3f79a3b5_d200fa6b","updated":"2018-11-27 10:08:34.000000000","message":"I think this should be called from the script as this is the only case when stamping is needed.","commit_id":"fe30a44e9d61c83c55446c2665b811c77ffe565d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5166f5ec0813c6092a43a5c8410343ea44159aa8","unresolved":false,"context_lines":[{"line_number":164,"context_line":"scripts which can assist with migrating placement data from the nova-api"},{"line_number":165,"context_line":"database to the placement database. You can find them in the `placement"},{"line_number":166,"context_line":"repository`_, ``/tools/mysql-migrate-db.sh`` and"},{"line_number":167,"context_line":"``/tools/postgresql-migrate-db.sh``. Note that after you migrate the tables,"},{"line_number":168,"context_line":"you should stamp the version explicitly via the"},{"line_number":169,"context_line":"``placement-manage db stamp b4ed3a175331`` command. Otherwise, syncing the"},{"line_number":170,"context_line":"database version fails because it tries to create migrated tables again on"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_fe229ca5","line":167,"updated":"2018-11-27 14:35:02.000000000","message":"Wonder if we should add a --stable option, or just automatically try to stamp the version from the db migration scripts, since that would cut down a step in the upgrade.\n\nI guess we didn\u0027t hit this when adding the grenade/devstack change because there were no new data migrations in placement, and the new placement change that does a data migration [1] isn\u0027t running grenade/tempest yet [2].\n\n[1] https://review.openstack.org/#/c/619126/\n[2] https://review.openstack.org/#/c/617565/","commit_id":"bc1515ec456f1f9f83e905e45270ac6fcc40eef2"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"2d3e83487d82514dcc48a90cadb9b3adf40610c3","unresolved":false,"context_lines":[{"line_number":164,"context_line":"scripts which can assist with migrating placement data from the nova-api"},{"line_number":165,"context_line":"database to the placement database. You can find them in the `placement"},{"line_number":166,"context_line":"repository`_, ``/tools/mysql-migrate-db.sh`` and"},{"line_number":167,"context_line":"``/tools/postgresql-migrate-db.sh``. Note that after you migrate the tables,"},{"line_number":168,"context_line":"you should stamp the version explicitly via the"},{"line_number":169,"context_line":"``placement-manage db stamp b4ed3a175331`` command. Otherwise, syncing the"},{"line_number":170,"context_line":"database version fails because it tries to create migrated tables again on"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_86022f06","line":167,"in_reply_to":"3f79a3b5_eb596e29","updated":"2018-11-28 08:15:17.000000000","message":"\u003e I\u0027m looking into adding this to the grenade script [3]. My guess is that we didn\u0027t hit this just because grenade\u0027s doesn\u0027t execute db sync after the upgrade.... thoughts?\n\n[Later] I saw Matt\u0027s comment on [1] https://review.openstack.org/#/c/619126/ and I\u0027ve just rebased it. I was misunderstanding that the grenade job had already been executed. Anyway, let\u0027s see what happens.","commit_id":"bc1515ec456f1f9f83e905e45270ac6fcc40eef2"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"ed2c4471c288be691ba05fbd4cc74d3d9c3e3634","unresolved":false,"context_lines":[{"line_number":164,"context_line":"scripts which can assist with migrating placement data from the nova-api"},{"line_number":165,"context_line":"database to the placement database. You can find them in the `placement"},{"line_number":166,"context_line":"repository`_, ``/tools/mysql-migrate-db.sh`` and"},{"line_number":167,"context_line":"``/tools/postgresql-migrate-db.sh``. Note that after you migrate the tables,"},{"line_number":168,"context_line":"you should stamp the version explicitly via the"},{"line_number":169,"context_line":"``placement-manage db stamp b4ed3a175331`` command. Otherwise, syncing the"},{"line_number":170,"context_line":"database version fails because it tries to create migrated tables again on"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_eb596e29","line":167,"in_reply_to":"3f79a3b5_fe229ca5","updated":"2018-11-28 07:36:09.000000000","message":"\u003e Wonder if we should add a --stable option, or just automatically\n \u003e try to stamp the version from the db migration scripts, since that\n \u003e would cut down a step in the upgrade.\n\nWell, we don\u0027t want the data migration scripts `/tools/*-migrate-db.sh` to include placement commands, do we? That said now the migration scripts are generic enough to execute before placement installation. And sorry, I couldn\u0027t catch what you meant by \"we should add a --stable option\".\n\n \u003e I guess we didn\u0027t hit this when adding the grenade/devstack change\n \u003e because there were no new data migrations in placement, and the new\n \u003e placement change that does a data migration [1] isn\u0027t running\n \u003e grenade/tempest yet [2].\n \u003e \n \u003e [1] https://review.openstack.org/#/c/619126/\n \u003e [2] https://review.openstack.org/#/c/617565/\n\nI\u0027m looking into adding this to the grenade script [3]. My guess is that we didn\u0027t hit this just because grenade\u0027s doesn\u0027t execute db sync after the upgrade.... thoughts?\n\n[3] https://review.openstack.org/#/c/620485/","commit_id":"bc1515ec456f1f9f83e905e45270ac6fcc40eef2"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"60f712d43b841d176448aae4a0f02e10da24da03","unresolved":false,"context_lines":[{"line_number":164,"context_line":"scripts which can assist with migrating placement data from the nova-api"},{"line_number":165,"context_line":"database to the placement database. You can find them in the `placement"},{"line_number":166,"context_line":"repository`_, ``/tools/mysql-migrate-db.sh`` and"},{"line_number":167,"context_line":"``/tools/postgresql-migrate-db.sh``. Note that after you migrate the tables,"},{"line_number":168,"context_line":"you should stamp the version explicitly via the"},{"line_number":169,"context_line":"``placement-manage db stamp b4ed3a175331`` command. Otherwise, syncing the"},{"line_number":170,"context_line":"database version fails because it tries to create migrated tables again on"},{"line_number":171,"context_line":"the initial version upgrade: (initial) -\u003e (b4ed3a175331)."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"**3. Create accounts and update the service catalog**"},{"line_number":174,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"3f79a3b5_66b8d712","line":171,"range":{"start_line":167,"start_character":37,"end_line":171,"end_character":57},"updated":"2018-12-03 15:21:54.000000000","message":"Why not just do this automatically at the successful completion of either the /tools/mysql-migrate-db.sh or /tools/postgresql-migrate-db.sh script? Otherwise, it\u0027s just one more step that needs to be taken by an operator that is likely to be missed...","commit_id":"e4e10b4294f811cd88e1573962bc2b01704ae521"}],"placement/db/sqlalchemy/migration.py":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"425cae10b4e8c2040afd65b629e6fcfacba832d0","unresolved":false,"context_lines":[{"line_number":71,"context_line":"    :param version: Database version to stamp"},{"line_number":72,"context_line":"    :type version: string"},{"line_number":73,"context_line":"    \"\"\""},{"line_number":74,"context_line":"    config \u003d config or _alembic_config()"},{"line_number":75,"context_line":"    alembic.command.stamp(config, version)"}],"source_content_type":"text/x-python","patch_set":3,"id":"3f79a3b5_cd7e1f6c","line":74,"updated":"2018-11-27 10:08:34.000000000","message":"This is a pretty dangerous command. Can we limit the usage of it to the initial -\u003e b4ed3a175331 stamping?","commit_id":"fe30a44e9d61c83c55446c2665b811c77ffe565d"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"76dd9c8794c430f47c03e214262002ed3f4f2197","unresolved":false,"context_lines":[{"line_number":71,"context_line":"    :param version: Database version to stamp"},{"line_number":72,"context_line":"    :type version: string"},{"line_number":73,"context_line":"    \"\"\""},{"line_number":74,"context_line":"    config \u003d config or _alembic_config()"},{"line_number":75,"context_line":"    alembic.command.stamp(config, version)"}],"source_content_type":"text/x-python","patch_set":3,"id":"3f79a3b5_9395a4e4","line":74,"in_reply_to":"3f79a3b5_cd7e1f6c","updated":"2018-11-27 12:12:00.000000000","message":"Well, if we have the version check here, we can limit it, but I don\u0027t think we should expose such API. Stamping b4ed3a175331 implicitly is not a good idea either, because we shouldn\u0027t do that if we are ahead of it. \n\nI think this is okay because:\n(1) this allows people to move to alembic management scheme any time you want, and to migrate DB to another DB by copying the contents for some reason anytime you want\n(2) some other projects have been exposing this, which means this hasn\u0027t brought a big problem so far\n(3) even if we stamp a wrong version, we can just re-stamp it with the correct version again.","commit_id":"fe30a44e9d61c83c55446c2665b811c77ffe565d"}]}