)]}'
{"nova/db/sqlalchemy/migrate_repo/versions/254_juno.py":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"3fa520c82fa5a158ff7a12c3aaeb00ac8762004a","unresolved":false,"context_lines":[{"line_number":1416,"context_line":"            # so they match Havana"},{"line_number":1417,"context_line":"            fkey \u003d ForeignKeyConstraint("},{"line_number":1418,"context_line":"                columns\u003dfkey_pair[0], refcolumns\u003dfkey_pair[1],"},{"line_number":1419,"context_line":"                name\u003dfkey_pair[2])"},{"line_number":1420,"context_line":"            fkey.create()"},{"line_number":1421,"context_line":"        elif migrate_engine.name \u003d\u003d \u0027postgresql\u0027:"},{"line_number":1422,"context_line":"            # PostgreSQL names things like it wants (correct and compatible!)"}],"source_content_type":"text/x-python","patch_set":3,"id":"570b938e_7019f848","line":1419,"updated":"2020-12-21 09:45:13.000000000","message":"Here","commit_id":"2c3a648df7dcc316961b91cb9e6f6018e114f1c2"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ee3d6e3f5c7c5324ef00426765195371d9ff62ef","unresolved":true,"context_lines":[{"line_number":1428,"context_line":"    fkey \u003d ForeignKeyConstraint("},{"line_number":1429,"context_line":"        columns\u003d[pci_devices.c.compute_node_id],"},{"line_number":1430,"context_line":"        refcolumns\u003d[compute_nodes.c.id])"},{"line_number":1431,"context_line":"    fkey.create()"},{"line_number":1432,"context_line":""},{"line_number":1433,"context_line":"    fkey \u003d ForeignKeyConstraint("},{"line_number":1434,"context_line":"        columns\u003d[instance_extra.c.instance_uuid],"}],"source_content_type":"text/x-python","patch_set":3,"id":"504a262d_005460df","line":1431,"updated":"2020-12-18 15:47:36.000000000","message":"Is this equivalent of adding the following new item to the `fkeys` list above?\n\n  [\n      [pci_devices.c.compute_node_id], \n      [compute_nodes.c.id], \n      \u0027fk_pci_devices_compute_node_id\u0027\n  ]","commit_id":"2c3a648df7dcc316961b91cb9e6f6018e114f1c2"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"3fa520c82fa5a158ff7a12c3aaeb00ac8762004a","unresolved":false,"context_lines":[{"line_number":1428,"context_line":"    fkey \u003d ForeignKeyConstraint("},{"line_number":1429,"context_line":"        columns\u003d[pci_devices.c.compute_node_id],"},{"line_number":1430,"context_line":"        refcolumns\u003d[compute_nodes.c.id])"},{"line_number":1431,"context_line":"    fkey.create()"},{"line_number":1432,"context_line":""},{"line_number":1433,"context_line":"    fkey \u003d ForeignKeyConstraint("},{"line_number":1434,"context_line":"        columns\u003d[instance_extra.c.instance_uuid],"}],"source_content_type":"text/x-python","patch_set":3,"id":"b1877438_5c10cac2","line":1431,"in_reply_to":"504a262d_005460df","updated":"2020-12-21 09:45:13.000000000","message":"Not exactly. The list above has the form \"source, dest, name\", where \"source\" points to \"dest\" and the FK has the name \"name\". You\u0027ll note that the name argument is missing here and obviously in the original. I didn\u0027t want to rework the loop above [1] to handle a missing name so I kept this separate with a TODO to resolve.\n\n[1] https://review.opendev.org/c/openstack/nova/+/758395/3/nova/db/sqlalchemy/migrate_repo/versions/254_juno.py#1419","commit_id":"2c3a648df7dcc316961b91cb9e6f6018e114f1c2"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7fadab11e926984cbcb72848affc63e4cf17ed47","unresolved":false,"context_lines":[{"line_number":1428,"context_line":"    fkey \u003d ForeignKeyConstraint("},{"line_number":1429,"context_line":"        columns\u003d[pci_devices.c.compute_node_id],"},{"line_number":1430,"context_line":"        refcolumns\u003d[compute_nodes.c.id])"},{"line_number":1431,"context_line":"    fkey.create()"},{"line_number":1432,"context_line":""},{"line_number":1433,"context_line":"    fkey \u003d ForeignKeyConstraint("},{"line_number":1434,"context_line":"        columns\u003d[instance_extra.c.instance_uuid],"}],"source_content_type":"text/x-python","patch_set":3,"id":"b5dd70e8_2e7258e0","line":1431,"in_reply_to":"b1877438_5c10cac2","updated":"2021-01-05 08:33:57.000000000","message":"I see. thanks for the explanation.","commit_id":"2c3a648df7dcc316961b91cb9e6f6018e114f1c2"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ee3d6e3f5c7c5324ef00426765195371d9ff62ef","unresolved":true,"context_lines":[{"line_number":1452,"context_line":"    # apply to shadow tables also"},{"line_number":1453,"context_line":""},{"line_number":1454,"context_line":"    table \u003d Table(\u0027volume_usage_cache\u0027, meta, autoload\u003dTrue)"},{"line_number":1455,"context_line":"    table.c.user_id.alter(type\u003dString(64))"},{"line_number":1456,"context_line":""},{"line_number":1457,"context_line":"    # 247_nullable_mismatch; these alterations should apply to shadow tables"},{"line_number":1458,"context_line":"    # also"}],"source_content_type":"text/x-python","patch_set":3,"id":"50fdc07c_fc4fff15","line":1455,"updated":"2020-12-18 15:47:36.000000000","message":"Do I understand correctly? So we are not doing this change in the volume_usage_cache table definition directly as that would diverge the database schemas between a new deployment, where both volume_usage_cache and shadow_volume_usage_cache would have user_id as String(64), an between a db that was upgraded from before Juno, where only the volume_usage_cache.user_id is altered to String(64).\n\nSo what would be the solution? Add a new migration that alter the shadow_volume_usage_cache.user_id to String(64)?\n\nAm I correct that we cannot add such alteration here as there might be deployment out there that already upgraded from before Juno to over Juno and therefore having their shadow_volume_usage_cache.user_id as String(32) and they will not run 254_juno migration any more.","commit_id":"2c3a648df7dcc316961b91cb9e6f6018e114f1c2"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"3fa520c82fa5a158ff7a12c3aaeb00ac8762004a","unresolved":false,"context_lines":[{"line_number":1452,"context_line":"    # apply to shadow tables also"},{"line_number":1453,"context_line":""},{"line_number":1454,"context_line":"    table \u003d Table(\u0027volume_usage_cache\u0027, meta, autoload\u003dTrue)"},{"line_number":1455,"context_line":"    table.c.user_id.alter(type\u003dString(64))"},{"line_number":1456,"context_line":""},{"line_number":1457,"context_line":"    # 247_nullable_mismatch; these alterations should apply to shadow tables"},{"line_number":1458,"context_line":"    # also"}],"source_content_type":"text/x-python","patch_set":3,"id":"62301c36_ee5c107c","line":1455,"in_reply_to":"50fdc07c_fc4fff15","updated":"2020-12-21 09:45:13.000000000","message":"\u003e Do I understand correctly? So we are not doing this change in the volume_usage_cache table definition directly as that would diverge the database schemas between a new deployment, where both volume_usage_cache and shadow_volume_usage_cache would have user_id as String(64), an between a db that was upgraded from before Juno, where only the volume_usage_cache.user_id is altered to String(64).\n\nYes. Prior to this squash, shadow_volume_usage_cache will *not* have user_id as String(64). We want to preserve that behavior, even if it\u0027s broken, so that we can fix it in the future for existing deployments.\n\n\u003e So what would be the solution? Add a new migration that alter the shadow_volume_usage_cache.user_id to String(64)?\n\nYup. I\u0027m going to wait to do this (the TODO will remind me) because I\u0027d like to do it with alembic.\n\n\u003e Am I correct that we cannot add such alteration here as there might be deployment out there that already upgraded from before Juno to over Juno and therefore having their shadow_volume_usage_cache.user_id as String(32) and they will not run 254_juno migration any more.\n\nYes, exactly. At the end of this squashing, users who have upgraded using the unsquashed migration should have an identical schema to those starting with a new deployment.","commit_id":"2c3a648df7dcc316961b91cb9e6f6018e114f1c2"}]}