)]}'
{"ceilometer/storage/impl_sqlalchemy.py":[{"author":{"_account_id":6537,"name":"gordon chung","email":"gord@live.ca","username":"chungg"},"change_message_id":"13c5f33d7053fcf1af62dd2452f63a1c0ee28b28","unresolved":false,"context_lines":[{"line_number":287,"context_line":"                                       \"not be queryable.\"), key)"},{"line_number":288,"context_line":"                        else:"},{"line_number":289,"context_line":"                            session.add(_model(id\u003dmeter.id,"},{"line_number":290,"context_line":"                                               meta_key\u003dkey.replace(\u0027:\u0027, \u0027.\u0027),"},{"line_number":291,"context_line":"                                               value\u003dv))"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"    @staticmethod"}],"source_content_type":"text/x-python","patch_set":2,"id":"AAAAUH%2F%2FRYc%3D","line":290,"updated":"2014-01-15 16:34:50.000000000","message":"is this to get around the recursive_keypairs() bug? maybe just make this dependent on that fix and use the separator param above.","commit_id":"c9c5e03cef0c08606fb40727c1586122b9a5e61e"},{"author":{"_account_id":7478,"name":"Nadya Shakhat","email":"nadmi4@gmail.com","username":"nprivalova"},"change_message_id":"8974be214309855814b760c642f514750dc52587","unresolved":false,"context_lines":[{"line_number":287,"context_line":"                                       \"not be queryable.\"), key)"},{"line_number":288,"context_line":"                        else:"},{"line_number":289,"context_line":"                            session.add(_model(id\u003dmeter.id,"},{"line_number":290,"context_line":"                                               meta_key\u003dkey.replace(\u0027:\u0027, \u0027.\u0027),"},{"line_number":291,"context_line":"                                               value\u003dv))"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"    @staticmethod"}],"source_content_type":"text/x-python","patch_set":2,"id":"AAAAUH%2F%2FQdY%3D","line":290,"in_reply_to":"AAAAUH%2F%2FRYc%3D","updated":"2014-01-15 20:39:34.000000000","message":"yes, Gordon, you\u0027re right. I forgot to add comment about this. But I\u0027m not sure how to fix that...It\u0027s related to https://bugs.launchpad.net/ceilometer/+bug/1268628 . The problem is that if I fix this, flatten_metedata will start to return another format \"a.a.a\" instead of \"a.a:a\". Of course I can add a hack. So that\u0027s why I decided not to fix it now","commit_id":"c9c5e03cef0c08606fb40727c1586122b9a5e61e"}],"ceilometer/storage/sqlalchemy/migrate_repo/versions/025_change_metadata_format.py":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"378b8103d98b993ea0a0438fb733f5ce2958edf1","unresolved":false,"context_lines":[{"line_number":38,"context_line":"    meta_tables \u003d get_meta_tables(meta)"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"    meter \u003d Table(\u0027meter\u0027, meta, autoload\u003dTrue)"},{"line_number":41,"context_line":"    for row in select([meter]).execute():"},{"line_number":42,"context_line":"        if row[\u0027resource_metadata\u0027]:"},{"line_number":43,"context_line":"            meter_id \u003d row[\u0027id\u0027]"},{"line_number":44,"context_line":"            rmeta \u003d json.loads(row[\u0027resource_metadata\u0027])"}],"source_content_type":"text/x-python","patch_set":1,"id":"AAAAUH%2F%2FWdQ%3D","line":41,"updated":"2014-01-14 19:09:37.000000000","message":"Danger, Will Robinson. On most OpenStack deployments, the above is going to be returning an *enormous* amount of records.\n\nIn our small (~100 compute node) zones, only running for around 2-3 months, the above would easily return half a *billion* records. I would almost guarantee that the upgrade migration would time out attempting to create a single transaction containing half a billion UPDATE statements.\n\nI believe that because we are dealing with the base meter fact table here, we need to use a batched UPDATE process that COMMITs every 1000 records or so, and logging statements should likely be put into this migration script so that admins can have some way of tracking what will be a *very* long migration runtime.\n\nI\u0027m thinking something like this would work best:\n\n meter_id \u003d 0\n while True:\n   s \u003d select([meter], meter.id \u003e meter_id).order_by(meter.id).limit(1000)\n   if not s:\n     break\n   LOG.info(\"Migrating \u003c\u003d1000 meters starting from meter ID %s\", meter_id)\n   with session.begin():\n     for row in s:\n       meter_id \u003d row[\u0027id\u0027]\n       # ... perform the translation code from below ...\n       ins.values(...).execute()","commit_id":"a2bb4feafa0310c8fb6e0b74795f1a91e408e615"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"378b8103d98b993ea0a0438fb733f5ce2958edf1","unresolved":false,"context_lines":[{"line_number":63,"context_line":"    meta_tables \u003d get_meta_tables(meta)"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"    meter \u003d Table(\u0027meter\u0027, meta, autoload\u003dTrue)"},{"line_number":66,"context_line":"    for row in select([meter]).execute():"},{"line_number":67,"context_line":"        if row[\u0027resource_metadata\u0027]:"},{"line_number":68,"context_line":"            meter_id \u003d row[\u0027id\u0027]"},{"line_number":69,"context_line":"            rmeta \u003d json.loads(row[\u0027resource_metadata\u0027])"}],"source_content_type":"text/x-python","patch_set":1,"id":"AAAAUH%2F%2FWdM%3D","line":66,"updated":"2014-01-14 19:09:37.000000000","message":"Same remark as above.","commit_id":"a2bb4feafa0310c8fb6e0b74795f1a91e408e615"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"378b8103d98b993ea0a0438fb733f5ce2958edf1","unresolved":false,"context_lines":[{"line_number":38,"context_line":"    meta_tables \u003d get_meta_tables(meta)"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"    meter \u003d Table(\u0027meter\u0027, meta, autoload\u003dTrue)"},{"line_number":41,"context_line":"    for row in select([meter]).execute():"},{"line_number":42,"context_line":"        if row[\u0027resource_metadata\u0027]:"},{"line_number":43,"context_line":"            meter_id \u003d row[\u0027id\u0027]"},{"line_number":44,"context_line":"            rmeta \u003d json.loads(row[\u0027resource_metadata\u0027])"}],"source_content_type":"text/x-python","patch_set":2,"id":"AAAAUH%2F%2FWVE%3D","line":41,"updated":"2014-01-14 19:11:54.000000000","message":"Danger, Will Robinson. On most OpenStack deployments, the above is going to be returning an *enormous* amount of records.\n\nIn our small (~100 compute node) zones, only running for around 2-3 months, the above would easily return half a *billion* records. I would almost guarantee that the upgrade migration would time out attempting to create a single transaction containing half a billion UPDATE statements.\n\nI believe that because we are dealing with the base meter fact table here, we need to use a batched UPDATE process that COMMITs every 1000 records or so, and logging statements should likely be put into this migration script so that admins can have some way of tracking what will be a *very* long migration runtime.\n\nI\u0027m thinking something like this would work best:\n\n meter_id \u003d 0\n while True:\n   s \u003d select([meter], meter.id \u003e meter_id).order_by(meter.id).limit(1000)\n   if not s:\n     break\n   LOG.info(\"Migrating \u003c\u003d1000 meters starting from meter ID %s\", meter_id)\n   with session.begin():\n     for row in s:\n       meter_id \u003d row[\u0027id\u0027]\n       # ... perform the translation code from below ...\n       ins.values(...).execute()","commit_id":"c9c5e03cef0c08606fb40727c1586122b9a5e61e"},{"author":{"_account_id":7478,"name":"Nadya Shakhat","email":"nadmi4@gmail.com","username":"nprivalova"},"change_message_id":"71583cc16c388c9661c498e1a9d35b6ce8b12431","unresolved":false,"context_lines":[{"line_number":38,"context_line":"    meta_tables \u003d get_meta_tables(meta)"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"    meter \u003d Table(\u0027meter\u0027, meta, autoload\u003dTrue)"},{"line_number":41,"context_line":"    for row in select([meter]).execute():"},{"line_number":42,"context_line":"        if row[\u0027resource_metadata\u0027]:"},{"line_number":43,"context_line":"            meter_id \u003d row[\u0027id\u0027]"},{"line_number":44,"context_line":"            rmeta \u003d json.loads(row[\u0027resource_metadata\u0027])"}],"source_content_type":"text/x-python","patch_set":2,"id":"AAAAUH%2F%2FWRw%3D","line":41,"in_reply_to":"AAAAUH%2F%2FWVE%3D","updated":"2014-01-14 19:23:00.000000000","message":"Thanks, Jay! I think this comment may be applied to existing migration scripts...Because they will timed out before mine:)","commit_id":"c9c5e03cef0c08606fb40727c1586122b9a5e61e"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"378b8103d98b993ea0a0438fb733f5ce2958edf1","unresolved":false,"context_lines":[{"line_number":62,"context_line":"    clean_meta_tables(meta)"},{"line_number":63,"context_line":"    meta_tables \u003d get_meta_tables(meta)"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"    meter \u003d Table(\u0027meter\u0027, meta, autoload\u003dTrue)"},{"line_number":66,"context_line":"    for row in select([meter]).execute():"},{"line_number":67,"context_line":"        if row[\u0027resource_metadata\u0027]:"},{"line_number":68,"context_line":"            meter_id \u003d row[\u0027id\u0027]"}],"source_content_type":"text/x-python","patch_set":2,"id":"AAAAUH%2F%2FWU8%3D","line":65,"updated":"2014-01-14 19:11:54.000000000","message":"Same as above.","commit_id":"c9c5e03cef0c08606fb40727c1586122b9a5e61e"}]}