)]}'
{"specs/newton/approved/live_migration_compute_communcation.rst":[{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"c5b50c5be3d0e408555dbd96d3ccfa1fb5340204","unresolved":false,"context_lines":[{"line_number":52,"context_line":"failure."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":55,"context_line":"rpc-calls: once request received by service it stores its info on local storage"},{"line_number":56,"context_line":"and then spawn new thread to make process async. This mechanics allows sender"},{"line_number":57,"context_line":"to be confient that receiver received and start to work on current request."},{"line_number":58,"context_line":"Local storage is implemented as in-memory dictionary with dumping to file"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a122d0e_fbb4c3f1","line":55,"updated":"2016-05-05 13:45:24.000000000","message":"Can we do this first step without using local storage? I think there are real benefits to having it at some point, but since this is an entirely new thing there are concerns to address like upgrades, timeouts, where to put it, shared filesystems, etc...\n\nJust altering the workflow to have conductor orchestrate the live-migration is useful and shouldn\u0027t make anything worse than it is now. Adding local state to computes for cleanups is a separate effort.","commit_id":"fa25b69ff1e31f72cbf4dcc37fd1bb32b38631b3"},{"author":{"_account_id":14131,"name":"shaohef","email":"shaohe.feng@intel.com","username":"shaohefeng"},"change_message_id":"4b88f06cbec7b9d109225bb6610b89641a6744df","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* rollback_live_migration_async - cleans up node in case of live-migration"},{"line_number":52,"context_line":"failure."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":55,"context_line":"rpc-calls: once request received by service it stores its info on local storage"},{"line_number":56,"context_line":"and then spawn new thread to make process async. This mechanics allows sender"},{"line_number":57,"context_line":"to be confient that receiver received and start to work on current request."},{"line_number":58,"context_line":"Local storage is implemented as in-memory dictionary with dumping to file"},{"line_number":59,"context_line":"current state on every update. This dump will be read once compute host is"},{"line_number":60,"context_line":"started after potential fail. Using such local state storage allows to take"},{"line_number":61,"context_line":"into account situation when process is silently fails and no ways to clean up"},{"line_number":62,"context_line":"host in such case other than manually clean up failed host."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3afc51ec_b6fa7fbb","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":59},"updated":"2016-03-15 03:42:32.000000000","message":"hi, Timofey Durakov. \n\nSo  here is the conductor receiver?\nconductor store/update/read the local  storage?","commit_id":"fa25b69ff1e31f72cbf4dcc37fd1bb32b38631b3"},{"author":{"_account_id":1865,"name":"Andrea Rosa","email":"andrea.rosa@gmail.com","username":"andrea-rosa-m"},"change_message_id":"ae654aec7b26e3f2d69460cc933f2c3496e2295e","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* rollback_live_migration_async - cleans up node in case of live-migration"},{"line_number":52,"context_line":"failure."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":55,"context_line":"rpc-calls: once request received by service it stores its info on local storage"},{"line_number":56,"context_line":"and then spawn new thread to make process async. This mechanics allows sender"},{"line_number":57,"context_line":"to be confient that receiver received and start to work on current request."},{"line_number":58,"context_line":"Local storage is implemented as in-memory dictionary with dumping to file"},{"line_number":59,"context_line":"current state on every update. This dump will be read once compute host is"},{"line_number":60,"context_line":"started after potential fail. Using such local state storage allows to take"},{"line_number":61,"context_line":"into account situation when process is silently fails and no ways to clean up"},{"line_number":62,"context_line":"host in such case other than manually clean up failed host."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1af94dfe_76e4e40c","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":59},"in_reply_to":"1af94dfe_73ca3b51","updated":"2016-03-15 16:08:03.000000000","message":"I miss a point, where is it the orchestrator? What is going to check when an async call is terminated and call the next one?","commit_id":"fa25b69ff1e31f72cbf4dcc37fd1bb32b38631b3"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"68b674a5d997bf400a49112c220535ba58970d79","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* rollback_live_migration_async - cleans up node in case of live-migration"},{"line_number":52,"context_line":"failure."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":55,"context_line":"rpc-calls: once request received by service it stores its info on local storage"},{"line_number":56,"context_line":"and then spawn new thread to make process async. This mechanics allows sender"},{"line_number":57,"context_line":"to be confient that receiver received and start to work on current request."},{"line_number":58,"context_line":"Local storage is implemented as in-memory dictionary with dumping to file"},{"line_number":59,"context_line":"current state on every update. This dump will be read once compute host is"},{"line_number":60,"context_line":"started after potential fail. Using such local state storage allows to take"},{"line_number":61,"context_line":"into account situation when process is silently fails and no ways to clean up"},{"line_number":62,"context_line":"host in such case other than manually clean up failed host."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a18252c_5edeb711","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":59},"in_reply_to":"1af94dfe_76e4e40c","updated":"2016-04-13 19:28:59.000000000","message":"Matthew: conductor removes the need to compute-compute communication which some deployers do not want. And while it will be proxied through rabbitmq in a lot of cases we can\u0027t make that assumption since there is a 0mq messaging driver which could be in use.\n\nWe have also been moving towards handling this sort of orchestration in conductor for a while now with the eventual goal of getting a proper task framework in place. A precursor to that work is consolidating the workflow to a single logical location which can later handle the more complex things we want to do like restarting tasks after a service restart. Having the workflow distributed among the computes makes that a bigger challenge.","commit_id":"fa25b69ff1e31f72cbf4dcc37fd1bb32b38631b3"},{"author":{"_account_id":12175,"name":"Eli Qiao","email":"qiaoliyong@gmail.com","username":"Eli"},"change_message_id":"da5b8438fcc4e4bcc2eb4e5221d7555dbed41e9b","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* rollback_live_migration_async - cleans up node in case of live-migration"},{"line_number":52,"context_line":"failure."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":55,"context_line":"rpc-calls: once request received by service it stores its info on local storage"},{"line_number":56,"context_line":"and then spawn new thread to make process async. This mechanics allows sender"},{"line_number":57,"context_line":"to be confient that receiver received and start to work on current request."},{"line_number":58,"context_line":"Local storage is implemented as in-memory dictionary with dumping to file"},{"line_number":59,"context_line":"current state on every update. This dump will be read once compute host is"},{"line_number":60,"context_line":"started after potential fail. Using such local state storage allows to take"},{"line_number":61,"context_line":"into account situation when process is silently fails and no ways to clean up"},{"line_number":62,"context_line":"host in such case other than manually clean up failed host."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3afc51ec_e1b9dc16","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":59},"in_reply_to":"3afc51ec_b243a841","updated":"2016-03-15 09:01:20.000000000","message":"hmm... if you have multiple conductor... how this work?","commit_id":"fa25b69ff1e31f72cbf4dcc37fd1bb32b38631b3"},{"author":{"_account_id":14819,"name":"Timofey Durakov","email":"timofei.nd@gmail.com","username":"tdurakov"},"change_message_id":"343414442aa9086c582d054e391b244ddaca3279","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* rollback_live_migration_async - cleans up node in case of live-migration"},{"line_number":52,"context_line":"failure."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":55,"context_line":"rpc-calls: once request received by service it stores its info on local storage"},{"line_number":56,"context_line":"and then spawn new thread to make process async. This mechanics allows sender"},{"line_number":57,"context_line":"to be confient that receiver received and start to work on current request."},{"line_number":58,"context_line":"Local storage is implemented as in-memory dictionary with dumping to file"},{"line_number":59,"context_line":"current state on every update. This dump will be read once compute host is"},{"line_number":60,"context_line":"started after potential fail. Using such local state storage allows to take"},{"line_number":61,"context_line":"into account situation when process is silently fails and no ways to clean up"},{"line_number":62,"context_line":"host in such case other than manually clean up failed host."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3afc51ec_b243a841","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":59},"in_reply_to":"3afc51ec_b6fa7fbb","updated":"2016-03-15 06:13:46.000000000","message":"Hi, local storage is on compute nodes only and is used to restore current live-migration state, e.g. in case of failures that leads nova compute service to fail.","commit_id":"fa25b69ff1e31f72cbf4dcc37fd1bb32b38631b3"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"f17a88c138d81e6f5e25327246c1abdcfb851550","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* rollback_live_migration_async - cleans up node in case of live-migration"},{"line_number":52,"context_line":"failure."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":55,"context_line":"rpc-calls: once request received by service it stores its info on local storage"},{"line_number":56,"context_line":"and then spawn new thread to make process async. This mechanics allows sender"},{"line_number":57,"context_line":"to be confient that receiver received and start to work on current request."},{"line_number":58,"context_line":"Local storage is implemented as in-memory dictionary with dumping to file"},{"line_number":59,"context_line":"current state on every update. This dump will be read once compute host is"},{"line_number":60,"context_line":"started after potential fail. Using such local state storage allows to take"},{"line_number":61,"context_line":"into account situation when process is silently fails and no ways to clean up"},{"line_number":62,"context_line":"host in such case other than manually clean up failed host."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1af94dfe_73ca3b51","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":59},"in_reply_to":"3afc51ec_c1978046","updated":"2016-03-15 15:06:20.000000000","message":"I still don\u0027t see what conductor brings to the party over direct compute-\u003ecompute communication here. The mix between sync and async calls is definitely a problem and we should fix them all up. I like the solution you\u0027ve gone with in your patch of a synchronous call which returns after its written local state and spawned a thread. It\u0027s a good general model which we could use in other places.\n\nHowever, I just don\u0027t see what bouncing through conductor does, other than add more rpc overhead. It\u0027s not doing a significant amount of work, so it\u0027s not moving load off compute hosts. Not that that\u0027s a valid goal anyway, given that conductor is centralised. It\u0027s also not orchestrating anything. It\u0027s literally just providing a hop.\n\nI like pretty much everything about this, other than the involvement of conductor.","commit_id":"fa25b69ff1e31f72cbf4dcc37fd1bb32b38631b3"},{"author":{"_account_id":14819,"name":"Timofey Durakov","email":"timofei.nd@gmail.com","username":"tdurakov"},"change_message_id":"9b13dc813f03d87ec203cf6ff9178fce08863f2f","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* rollback_live_migration_async - cleans up node in case of live-migration"},{"line_number":52,"context_line":"failure."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":55,"context_line":"rpc-calls: once request received by service it stores its info on local storage"},{"line_number":56,"context_line":"and then spawn new thread to make process async. This mechanics allows sender"},{"line_number":57,"context_line":"to be confient that receiver received and start to work on current request."},{"line_number":58,"context_line":"Local storage is implemented as in-memory dictionary with dumping to file"},{"line_number":59,"context_line":"current state on every update. This dump will be read once compute host is"},{"line_number":60,"context_line":"started after potential fail. Using such local state storage allows to take"},{"line_number":61,"context_line":"into account situation when process is silently fails and no ways to clean up"},{"line_number":62,"context_line":"host in such case other than manually clean up failed host."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Alternatives"},{"line_number":65,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3afc51ec_c1978046","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":59},"in_reply_to":"3afc51ec_e1b9dc16","updated":"2016-03-15 09:07:55.000000000","message":"we store local migration state on compute before step to be executed, if than as in example above compute service fails, nova will revert current local state at compute startup and asks conductor to schedule next action for live/migration, rollback for example. So ha env with multiple conductors doesn\u0027t affect anything in this case.","commit_id":"fa25b69ff1e31f72cbf4dcc37fd1bb32b38631b3"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"ea37125040749e0f680cad328978aa736efa5f71","unresolved":false,"context_lines":[{"line_number":47,"context_line":"* post_live_migration_async finishes process on destination node in case"},{"line_number":48,"context_line":"of success"},{"line_number":49,"context_line":"* rollback_live_migration_async - cleans up node in case of live-migration"},{"line_number":50,"context_line":"failure."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":53,"context_line":"rpc-calls: once request received by service  it spawns new thread to make"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bab6814e_c0f92e82","line":50,"updated":"2016-05-25 19:28:35.000000000","message":"Can you provide more detail about the full flow of live migration after this work? The conductor receives a migration request, then what happens? Which RPC methods are called, which return a response versus casting back a response? Try to make it clear to someone who is not familiar with the current live migrate process.","commit_id":"4a84333e5cbd98e2285cc3d5feba6765404836d8"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"38be5a43dfbd1d0446e032ca87493604d1ee476b","unresolved":false,"context_lines":[{"line_number":76,"context_line":"Proposed workflow:"},{"line_number":77,"context_line":"* check_can_live_migrate_destination - blocking rpc call from conductor to"},{"line_number":78,"context_line":"destination compute to check possibility of schedulled migration."},{"line_number":79,"context_line":"* check_can_live_migrate_source - blocking rpc call from conductor to compute"},{"line_number":80,"context_line":"to source compute to check possibility of schedulled migration."},{"line_number":81,"context_line":"* pre_live_migration - blocking rpc call from conductor to destination"},{"line_number":82,"context_line":"compute to prepare destination host for ongoing migration."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_7bddfd6f","line":79,"range":{"start_line":79,"start_character":67,"end_line":79,"end_character":77},"updated":"2016-05-27 13:56:34.000000000","message":"this should be removed.","commit_id":"e7187aaf394689f5b0d9170d49b71e2a4455c053"},{"author":{"_account_id":14819,"name":"Timofey Durakov","email":"timofei.nd@gmail.com","username":"tdurakov"},"change_message_id":"cd9f3ab4bf11fd5dfa0d26e3a02650487f24bae9","unresolved":false,"context_lines":[{"line_number":76,"context_line":"Proposed workflow:"},{"line_number":77,"context_line":"* check_can_live_migrate_destination - blocking rpc call from conductor to"},{"line_number":78,"context_line":"destination compute to check possibility of schedulled migration."},{"line_number":79,"context_line":"* check_can_live_migrate_source - blocking rpc call from conductor to compute"},{"line_number":80,"context_line":"to source compute to check possibility of schedulled migration."},{"line_number":81,"context_line":"* pre_live_migration - blocking rpc call from conductor to destination"},{"line_number":82,"context_line":"compute to prepare destination host for ongoing migration."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_946d0b35","line":79,"range":{"start_line":79,"start_character":67,"end_line":79,"end_character":77},"in_reply_to":"9abb7d3a_7bddfd6f","updated":"2016-05-27 16:53:46.000000000","message":"Done","commit_id":"e7187aaf394689f5b0d9170d49b71e2a4455c053"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"38be5a43dfbd1d0446e032ca87493604d1ee476b","unresolved":false,"context_lines":[{"line_number":94,"context_line":"* rollback_live_migration_at_source - non-blcoking rpc cast from conductor to"},{"line_number":95,"context_line":"source compute to clean up resources after failed attempt"},{"line_number":96,"context_line":"* rollback_live_migration_at_destination - non-blcoking rpc cast from conductor"},{"line_number":97,"context_line":"to destination compute to clean up resources after failed attempt"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"Alternatives"},{"line_number":100,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_5b3c792f","line":97,"updated":"2016-05-27 13:56:34.000000000","message":"After reading this section I wondered what the difference is from what is done now because the workflow seems the same. It took careful comparison to discover that the difference is things like check_can_live_migrate_source would be conductor-\u003ecompute vs compute-\u003e compute. It would be helpful to add notes highlighting these differences.","commit_id":"e7187aaf394689f5b0d9170d49b71e2a4455c053"},{"author":{"_account_id":14819,"name":"Timofey Durakov","email":"timofei.nd@gmail.com","username":"tdurakov"},"change_message_id":"cd9f3ab4bf11fd5dfa0d26e3a02650487f24bae9","unresolved":false,"context_lines":[{"line_number":94,"context_line":"* rollback_live_migration_at_source - non-blcoking rpc cast from conductor to"},{"line_number":95,"context_line":"source compute to clean up resources after failed attempt"},{"line_number":96,"context_line":"* rollback_live_migration_at_destination - non-blcoking rpc cast from conductor"},{"line_number":97,"context_line":"to destination compute to clean up resources after failed attempt"},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"Alternatives"},{"line_number":100,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_6bb525cc","line":97,"in_reply_to":"9abb7d3a_5b3c792f","updated":"2016-05-27 16:53:46.000000000","message":"In the following patch-set I\u0027ve explicitly highlighted main diffs. Is that ok, or it would be better to make things even more clear?","commit_id":"e7187aaf394689f5b0d9170d49b71e2a4455c053"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"38be5a43dfbd1d0446e032ca87493604d1ee476b","unresolved":false,"context_lines":[{"line_number":99,"context_line":"Alternatives"},{"line_number":100,"context_line":"------------"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Leave things as is, and not to change this communication."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Data model impact"},{"line_number":105,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_5b6ab91b","line":102,"updated":"2016-05-27 13:56:34.000000000","message":"Have you considered doing this as a full state machine? So rather than doing blocking calls from conductor-\u003ecompute just cast to compute and let compute cast back to a conductor to handle the next step?","commit_id":"e7187aaf394689f5b0d9170d49b71e2a4455c053"},{"author":{"_account_id":14819,"name":"Timofey Durakov","email":"timofei.nd@gmail.com","username":"tdurakov"},"change_message_id":"cd9f3ab4bf11fd5dfa0d26e3a02650487f24bae9","unresolved":false,"context_lines":[{"line_number":99,"context_line":"Alternatives"},{"line_number":100,"context_line":"------------"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Leave things as is, and not to change this communication."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"Data model impact"},{"line_number":105,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9abb7d3a_cbca514f","line":102,"in_reply_to":"9abb7d3a_5b6ab91b","updated":"2016-05-27 16:53:46.000000000","message":"Done","commit_id":"e7187aaf394689f5b0d9170d49b71e2a4455c053"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"e10363451e986fc792160d05358420f4f264e1d9","unresolved":false,"context_lines":[{"line_number":28,"context_line":"migration phase(post/rollback) methods could never be executed and it will be"},{"line_number":29,"context_line":"impossible to say whether all steps were passed or not. This problem is also"},{"line_number":30,"context_line":"result of mixing process orchestration and real logic. When request reaches"},{"line_number":31,"context_line":"conductor following workflow is happened:"},{"line_number":32,"context_line":"* check_can_live_migrate_destination - blocking rpc call from conductor to"},{"line_number":33,"context_line":"destination compute to check possibility of schedulled migration. Before"},{"line_number":34,"context_line":"sending response to conductor, destination node sends following request to the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_0e61a3d3","line":31,"updated":"2016-05-31 10:44:05.000000000","message":"Nit: The formatting of this section is not correct, but that can be a later fix up. Please checked the rendered html for this doc. And extra empty line before starting the list should do the trick, along with indenting the extra lines of the list.","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"e10363451e986fc792160d05358420f4f264e1d9","unresolved":false,"context_lines":[{"line_number":74,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":75,"context_line":"rpc-calls: once request received by service  it spawns new thread to make"},{"line_number":76,"context_line":"process async. This mechanics allows sender to be confient that receiver"},{"line_number":77,"context_line":"received and start to work on current request."},{"line_number":78,"context_line":"Conductor in this case will be responsible for all preparations and checks to"},{"line_number":79,"context_line":"be done before live migration, and rollback/post live-migration operations."},{"line_number":80,"context_line":"Proposed workflow:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_4ed56b1a","line":77,"updated":"2016-05-31 10:44:05.000000000","message":"So you mean an RPC call, that then creates a greenlet to process the request, so the conductor knows the caller has started processing the message? Some how the current test is confusing.\n\nI think we want a new line here, before the next bit of text.","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ada500148e6b558d007a4985582fb8acb75913c3","unresolved":false,"context_lines":[{"line_number":74,"context_line":"All rpc methods above should implement following pattern a.k.a. lightweight"},{"line_number":75,"context_line":"rpc-calls: once request received by service  it spawns new thread to make"},{"line_number":76,"context_line":"process async. This mechanics allows sender to be confient that receiver"},{"line_number":77,"context_line":"received and start to work on current request."},{"line_number":78,"context_line":"Conductor in this case will be responsible for all preparations and checks to"},{"line_number":79,"context_line":"be done before live migration, and rollback/post live-migration operations."},{"line_number":80,"context_line":"Proposed workflow:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_740f5e88","line":77,"in_reply_to":"9abb7d3a_4ed56b1a","updated":"2016-05-31 11:09:43.000000000","message":"Ok, lets make this clearer in a follow up patch.","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"2f17898c6d043b0920f0b5c7edd41ede1147f4dd","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* live_migration - non-blocking rpc cast from conductor to source compute that"},{"line_number":88,"context_line":"actually triggers live-migration"},{"line_number":89,"context_line":"After steps described above 2 scenarios could happen:"},{"line_number":90,"context_line":"- live-migration succeeded"},{"line_number":91,"context_line":"- live-migration failed"},{"line_number":92,"context_line":"In case of success following workflow will happen:"},{"line_number":93,"context_line":"* post_live_migration_at_source - non-blocking rpc cast from conductor to"},{"line_number":94,"context_line":"source compute after migration finished"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_fc889524","line":91,"range":{"start_line":90,"start_character":0,"end_line":91,"end_character":23},"updated":"2016-05-30 06:09:14.000000000","message":"how do you know the live-migration succeeded or failed as the live-migration call is async?","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":14819,"name":"Timofey Durakov","email":"timofei.nd@gmail.com","username":"tdurakov"},"change_message_id":"a0b81e0aec24c29a0ef25b2db297daffa8112170","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* live_migration - non-blocking rpc cast from conductor to source compute that"},{"line_number":88,"context_line":"actually triggers live-migration"},{"line_number":89,"context_line":"After steps described above 2 scenarios could happen:"},{"line_number":90,"context_line":"- live-migration succeeded"},{"line_number":91,"context_line":"- live-migration failed"},{"line_number":92,"context_line":"In case of success following workflow will happen:"},{"line_number":93,"context_line":"* post_live_migration_at_source - non-blocking rpc cast from conductor to"},{"line_number":94,"context_line":"source compute after migration finished"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_93581c8c","line":91,"range":{"start_line":90,"start_character":0,"end_line":91,"end_character":23},"in_reply_to":"9abb7d3a_383b1f9e","updated":"2016-05-31 10:26:02.000000000","message":"Right, I want to use the same pattern like is used for instance boot, in case of failure compute calls back to conductor.","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"ca61ca9282c07d19efe14d27199ca62481b7dcc8","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* live_migration - non-blocking rpc cast from conductor to source compute that"},{"line_number":88,"context_line":"actually triggers live-migration"},{"line_number":89,"context_line":"After steps described above 2 scenarios could happen:"},{"line_number":90,"context_line":"- live-migration succeeded"},{"line_number":91,"context_line":"- live-migration failed"},{"line_number":92,"context_line":"In case of success following workflow will happen:"},{"line_number":93,"context_line":"* post_live_migration_at_source - non-blocking rpc cast from conductor to"},{"line_number":94,"context_line":"source compute after migration finished"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_383b1f9e","line":91,"range":{"start_line":90,"start_character":0,"end_line":91,"end_character":23},"in_reply_to":"9abb7d3a_7fd772bf","updated":"2016-05-31 02:10:56.000000000","message":"From the above, all the post_* and rollback_* methods are called from conductor. But live_migration_monitor is on source node, do you mean there is callback back to the conductor from source node?","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"e10363451e986fc792160d05358420f4f264e1d9","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* live_migration - non-blocking rpc cast from conductor to source compute that"},{"line_number":88,"context_line":"actually triggers live-migration"},{"line_number":89,"context_line":"After steps described above 2 scenarios could happen:"},{"line_number":90,"context_line":"- live-migration succeeded"},{"line_number":91,"context_line":"- live-migration failed"},{"line_number":92,"context_line":"In case of success following workflow will happen:"},{"line_number":93,"context_line":"* post_live_migration_at_source - non-blocking rpc cast from conductor to"},{"line_number":94,"context_line":"source compute after migration finished"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_ce603b04","line":91,"range":{"start_line":90,"start_character":0,"end_line":91,"end_character":23},"in_reply_to":"9abb7d3a_93581c8c","updated":"2016-05-31 10:44:05.000000000","message":"It would be good just to say the conductor is called to report if it was a success or a failure. i.e. there must be new conductor RPC method(s) for the callback.","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":14819,"name":"Timofey Durakov","email":"timofei.nd@gmail.com","username":"tdurakov"},"change_message_id":"3a07809dff720a56a47b956cadf4cc808ea4bd39","unresolved":false,"context_lines":[{"line_number":87,"context_line":"* live_migration - non-blocking rpc cast from conductor to source compute that"},{"line_number":88,"context_line":"actually triggers live-migration"},{"line_number":89,"context_line":"After steps described above 2 scenarios could happen:"},{"line_number":90,"context_line":"- live-migration succeeded"},{"line_number":91,"context_line":"- live-migration failed"},{"line_number":92,"context_line":"In case of success following workflow will happen:"},{"line_number":93,"context_line":"* post_live_migration_at_source - non-blocking rpc cast from conductor to"},{"line_number":94,"context_line":"source compute after migration finished"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_7fd772bf","line":91,"range":{"start_line":90,"start_character":0,"end_line":91,"end_character":23},"in_reply_to":"9abb7d3a_fc889524","updated":"2016-05-30 09:05:30.000000000","message":"live_migration_monitor, on the source compute node owns live-migration state. There are callbacks methods for success and failure.","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"e10363451e986fc792160d05358420f4f264e1d9","unresolved":false,"context_lines":[{"line_number":91,"context_line":"- live-migration failed"},{"line_number":92,"context_line":"In case of success following workflow will happen:"},{"line_number":93,"context_line":"* post_live_migration_at_source - non-blocking rpc cast from conductor to"},{"line_number":94,"context_line":"source compute after migration finished"},{"line_number":95,"context_line":"* post_live_migration_at_destination - non-blocking rpc cast from conductor to"},{"line_number":96,"context_line":"destination compute"},{"line_number":97,"context_line":"In case of failure:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_ae53376a","line":94,"updated":"2016-05-31 10:44:05.000000000","message":"I don\u0027t think this is required.\n\nThe live-migration call can do this before saying live-migrate was a success, unless this is stuff that has to happen after post_live_migration_at_dest, (i think there are some bits that need to) in which case this is in the wrong place, it should be after the destination call.","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ada500148e6b558d007a4985582fb8acb75913c3","unresolved":false,"context_lines":[{"line_number":91,"context_line":"- live-migration failed"},{"line_number":92,"context_line":"In case of success following workflow will happen:"},{"line_number":93,"context_line":"* post_live_migration_at_source - non-blocking rpc cast from conductor to"},{"line_number":94,"context_line":"source compute after migration finished"},{"line_number":95,"context_line":"* post_live_migration_at_destination - non-blocking rpc cast from conductor to"},{"line_number":96,"context_line":"destination compute"},{"line_number":97,"context_line":"In case of failure:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_348036c0","line":94,"in_reply_to":"9abb7d3a_ae53376a","updated":"2016-05-31 11:09:43.000000000","message":"Ah, so this is a cast now anyways.","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"e10363451e986fc792160d05358420f4f264e1d9","unresolved":false,"context_lines":[{"line_number":95,"context_line":"* post_live_migration_at_destination - non-blocking rpc cast from conductor to"},{"line_number":96,"context_line":"destination compute"},{"line_number":97,"context_line":"In case of failure:"},{"line_number":98,"context_line":"* rollback_live_migration_at_source - non-blcoking rpc cast from conductor to"},{"line_number":99,"context_line":"source compute to clean up resources after failed attempt"},{"line_number":100,"context_line":"* rollback_live_migration_at_destination - non-blcoking rpc cast from conductor"},{"line_number":101,"context_line":"to destination compute to clean up resources after failed attempt."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_2ec3c7ee","line":98,"range":{"start_line":98,"start_character":38,"end_line":98,"end_character":50},"updated":"2016-05-31 10:44:05.000000000","message":"I think this might need to be a blocking call, as I think there might be an ordering issue between the work done on the source and destination?","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"ada500148e6b558d007a4985582fb8acb75913c3","unresolved":false,"context_lines":[{"line_number":95,"context_line":"* post_live_migration_at_destination - non-blocking rpc cast from conductor to"},{"line_number":96,"context_line":"destination compute"},{"line_number":97,"context_line":"In case of failure:"},{"line_number":98,"context_line":"* rollback_live_migration_at_source - non-blcoking rpc cast from conductor to"},{"line_number":99,"context_line":"source compute to clean up resources after failed attempt"},{"line_number":100,"context_line":"* rollback_live_migration_at_destination - non-blcoking rpc cast from conductor"},{"line_number":101,"context_line":"to destination compute to clean up resources after failed attempt."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9abb7d3a_54621a3f","line":98,"range":{"start_line":98,"start_character":38,"end_line":98,"end_character":50},"in_reply_to":"9abb7d3a_2ec3c7ee","updated":"2016-05-31 11:09:43.000000000","message":"seems these are also cast calls now anyways.","commit_id":"fb94a44c43eb1c3892049e92c7b3a2c79dba56e8"}]}