)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"1a493b77c2dd37b76826f62f991eb69391474780","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"scheduler prep_resize() is only necessary when rescheduling a cold"},{"line_number":10,"context_line":"migration, but all of this can be done in conductor."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"Change-Id: I4143aa011e18edcc609e1095f0054c3a8670bc86"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3ae8d1ca_55aa191a","line":11,"updated":"2014-05-27 15:44:51.000000000","message":"please reference blueprint here.","commit_id":"3a7191dc49e75d451fc1f530f87d141f5b6533b3"}],"specs/juno/move-prep-resize-to-conductor.rst":[{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"45cdbf3c18924162d27c4c5c962b1232b94543c0","unresolved":false,"context_lines":[{"line_number":27,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Quite straightforward change :"},{"line_number":30,"context_line":"  - port scheduler.prep_resize() to new conductor.prep_resize() method"},{"line_number":31,"context_line":"  - change call from compute_manager to conductor instead of scheduler"},{"line_number":32,"context_line":"  - deprecate scheduler.prep_resize() in the Scheduler API"},{"line_number":33,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7adec928_5d4934b6","line":30,"updated":"2014-05-22 16:04:37.000000000","message":"Nit: best not to indent these bullets and best to have spaces between each bullet.","commit_id":"3b0950905bdd24ea856862ca32691684d9e4ac83"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"45cdbf3c18924162d27c4c5c962b1232b94543c0","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Modify scheduler prep_resize to remove the call to compute.prep_resize() but"},{"line_number":38,"context_line":"the scheduler logic is then so thin that there is no need to keep it (basically"},{"line_number":39,"context_line":"only one call to select_destinations)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Data model impact"},{"line_number":42,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7adec928_fdda00e8","line":39,"updated":"2014-05-22 16:04:37.000000000","message":"Nit: Not even sure that is a real alternative.","commit_id":"3b0950905bdd24ea856862ca32691684d9e4ac83"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"f754cc07e8f244e9a375b8414477f6b3e09d7f5e","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Modify scheduler prep_resize to remove the call to compute.prep_resize() but"},{"line_number":38,"context_line":"the scheduler logic is then so thin that there is no need to keep it (basically"},{"line_number":39,"context_line":"only one call to select_destinations)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Data model impact"},{"line_number":42,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7adec928_09c83121","line":39,"in_reply_to":"7adec928_edf083cb","updated":"2014-05-23 12:52:20.000000000","message":"Ok, then I\u0027ll mention moving all prep_resize to conductor as alternative","commit_id":"3b0950905bdd24ea856862ca32691684d9e4ac83"},{"author":{"_account_id":100,"name":"Johannes Erdfelt","email":"johannes@erdfelt.com","username":"johannes.erdfelt"},"change_message_id":"93021374ec116e468957f5e8cadb3d1d7d26274d","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Modify scheduler prep_resize to remove the call to compute.prep_resize() but"},{"line_number":38,"context_line":"the scheduler logic is then so thin that there is no need to keep it (basically"},{"line_number":39,"context_line":"only one call to select_destinations)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Data model impact"},{"line_number":42,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7adec928_edf083cb","line":39,"in_reply_to":"7adec928_fdda00e8","updated":"2014-05-22 22:02:42.000000000","message":"Yeah. This alternative wouldn\u0027t work at all so it\u0027s not really an alternative.","commit_id":"3b0950905bdd24ea856862ca32691684d9e4ac83"},{"author":{"_account_id":4573,"name":"yunhong-jiang","email":"yunhong.jiang@intel.com","username":"yunhong-jiang"},"change_message_id":"186decf3892ec2be1b7d2930f9b12cac6b797e66","unresolved":false,"context_lines":[{"line_number":37,"context_line":"Modify scheduler prep_resize to remove the call to compute.prep_resize() but"},{"line_number":38,"context_line":"the scheduler logic is then so thin that there is no need to keep it (basically"},{"line_number":39,"context_line":"only one call to select_destinations)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Data model impact"},{"line_number":42,"context_line":"-----------------"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7adec928_c7f2c69a","line":40,"updated":"2014-05-22 20:51:59.000000000","message":"I\u0027m not sure if we really want to take this way. IMHO, the whole prep_resize flow should happen in conductor, instead of in compute manager. Currently it\u0027s in compute manager simply because of atomic operation for resource claim. If we move the whole prep_resize from compute manager to conductor, we don\u0027t need this effort anymore, and the conductor manager itself will do the retry.","commit_id":"3b0950905bdd24ea856862ca32691684d9e4ac83"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"f754cc07e8f244e9a375b8414477f6b3e09d7f5e","unresolved":false,"context_lines":[{"line_number":37,"context_line":"Modify scheduler prep_resize to remove the call to compute.prep_resize() but"},{"line_number":38,"context_line":"the scheduler logic is then so thin that there is no need to keep it (basically"},{"line_number":39,"context_line":"only one call to select_destinations)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Data model impact"},{"line_number":42,"context_line":"-----------------"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7adec928_e9722510","line":40,"in_reply_to":"7adec928_6de713e5","updated":"2014-05-23 12:52:20.000000000","message":"I agree with moving to conductor the whole prep_resize but we need to do baby steps. Here, the goal is just to remove what\u0027s in the scheduler, not reworking all cold migrations. \n\nI leave this point to another blueprint.","commit_id":"3b0950905bdd24ea856862ca32691684d9e4ac83"},{"author":{"_account_id":100,"name":"Johannes Erdfelt","email":"johannes@erdfelt.com","username":"johannes.erdfelt"},"change_message_id":"93021374ec116e468957f5e8cadb3d1d7d26274d","unresolved":false,"context_lines":[{"line_number":37,"context_line":"Modify scheduler prep_resize to remove the call to compute.prep_resize() but"},{"line_number":38,"context_line":"the scheduler logic is then so thin that there is no need to keep it (basically"},{"line_number":39,"context_line":"only one call to select_destinations)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Data model impact"},{"line_number":42,"context_line":"-----------------"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7adec928_6de713e5","line":40,"in_reply_to":"7adec928_c7f2c69a","updated":"2014-05-22 22:02:42.000000000","message":"I agree. Conductor is the natural place for all of prep_resize","commit_id":"3b0950905bdd24ea856862ca32691684d9e4ac83"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"e4d5ab3025c84650b4c9aacca0c545a1eddeb9eb","unresolved":false,"context_lines":[{"line_number":78,"context_line":"Other deployer impact"},{"line_number":79,"context_line":"---------------------"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Scheduler V3 API will have a new minor version with prep_resize deprecated."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Developer impact"},{"line_number":84,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_f58885e9","line":81,"updated":"2014-05-27 15:43:59.000000000","message":"No need to bump the version when deprecating things, but thats cool","commit_id":"3a7191dc49e75d451fc1f530f87d141f5b6533b3"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"3d18c4674b0ea8a34a062512b0e20e20eae558fe","unresolved":false,"context_lines":[{"line_number":79,"context_line":"---------------------"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Scheduler V3 API may have a new minor version with prep_resize deprecated for"},{"line_number":82,"context_line":"clarity purposes."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Developer impact"},{"line_number":85,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3ae8d1ca_39b1ad8f","line":82,"updated":"2014-05-29 19:09:12.000000000","message":"I don\u0027t think this is necessary.  For deprecation we typically remove the call from rpcapi and comment that it\u0027s deprecated and should be removed on the manager/driver side.  A version bump isn\u0027t needed.","commit_id":"cf4c52e8626934812711d1fb84b37a1397a0b54b"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2c55e71e2dd3eab12ab0e33155a44ee80341c1a9","unresolved":false,"context_lines":[{"line_number":79,"context_line":"---------------------"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Scheduler V3 API may have a new minor version with prep_resize deprecated for"},{"line_number":82,"context_line":"clarity purposes."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Developer impact"},{"line_number":85,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1ae5cdf2_b357fe01","line":82,"in_reply_to":"3ae8d1ca_39b1ad8f","updated":"2014-05-30 09:21:38.000000000","message":"OK thanks for the clarification. John already gave me that details, but now I understand :-)","commit_id":"cf4c52e8626934812711d1fb84b37a1397a0b54b"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"924633269c2a1e284f852d2c3a8cedbed1e08934","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"So as to prepare the scheduler to be a separate project, we need to remove"},{"line_number":14,"context_line":"all proxy calls from the scheduler to compute nodes."},{"line_number":15,"context_line":"prep_resize() is still in Scheduler V3 API, so we need to port it to conductor."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\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":"1ae5cdf2_29e1e829","line":15,"updated":"2014-06-05 23:06:42.000000000","message":"the scheduler has its own API? Do you mean to say above that the scheduler still issues prep_resize() calls directly to compute nodes?","commit_id":"b71d9fac5843025d6209f52872f7879943a33a04"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"b9aff39b2185858395d8d6dc38791459c883c457","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"So as to prepare the scheduler to be a separate project, we need to remove"},{"line_number":14,"context_line":"all proxy calls from the scheduler to compute nodes."},{"line_number":15,"context_line":"prep_resize() is still in Scheduler V3 API, so we need to port it to conductor."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d\u003d\u003d\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":"1ae5cdf2_2f59ba5b","line":15,"in_reply_to":"1ae5cdf2_29e1e829","updated":"2014-06-16 14:11:46.000000000","message":"Right, the currently RPC API for Scheduler is V3.0, which contains prep_resize() on the manager side.\n\nThis method issues calls to compute nodes directly, so it needs to be moved to conductor API instead. Below, I\u0027m saying where this scheduler API method is called, ie. only when a cold migration is failing once.","commit_id":"b71d9fac5843025d6209f52872f7879943a33a04"},{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"48c381d25de25ae2b79688907740c28ea396ef9c","unresolved":false,"context_lines":[{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"The idea is to pass out to the compute node the list of hosts that have been"},{"line_number":31,"context_line":"elected for the cold migration, and if by chance the migration is failing, the"},{"line_number":32,"context_line":"compute node will call back conductor.migrate_server with the list of hosts"},{"line_number":33,"context_line":"minus itself so that conductor knows what to reschedule."},{"line_number":34,"context_line":"The stop condition is when the list is empty, we raise an Exception."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_2c2edb42","line":31,"updated":"2014-06-25 11:40:14.000000000","message":"s/elected/selected/","commit_id":"390d5537b61e999a4fe021664ae2f207fab2d3db"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2c201a13cfad9c3d3e4cdc31605cb341285ce9fb","unresolved":false,"context_lines":[{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"The idea is to pass out to the compute node the list of hosts that have been"},{"line_number":31,"context_line":"elected for the cold migration, and if by chance the migration is failing, the"},{"line_number":32,"context_line":"compute node will call back conductor.migrate_server with the list of hosts"},{"line_number":33,"context_line":"minus itself so that conductor knows what to reschedule."},{"line_number":34,"context_line":"The stop condition is when the list is empty, we raise an Exception."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_e9b11245","line":31,"in_reply_to":"1ae5cdf2_2c2edb42","updated":"2014-06-26 13:04:03.000000000","message":"Done","commit_id":"390d5537b61e999a4fe021664ae2f207fab2d3db"},{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"48c381d25de25ae2b79688907740c28ea396ef9c","unresolved":false,"context_lines":[{"line_number":31,"context_line":"elected for the cold migration, and if by chance the migration is failing, the"},{"line_number":32,"context_line":"compute node will call back conductor.migrate_server with the list of hosts"},{"line_number":33,"context_line":"minus itself so that conductor knows what to reschedule."},{"line_number":34,"context_line":"The stop condition is when the list is empty, we raise an Exception."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"},{"line_number":37,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_6cad439b","line":34,"updated":"2014-06-25 11:40:14.000000000","message":"This isn\u0027t the flow used for re-scheduling initial requests - in that case the compute manager calls back to conductor, which asks the scheduler for a new list of nodes (and tells it which ones have already been tried).\n\nI don\u0027t see why we would want different logic for resize ?","commit_id":"390d5537b61e999a4fe021664ae2f207fab2d3db"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"2c201a13cfad9c3d3e4cdc31605cb341285ce9fb","unresolved":false,"context_lines":[{"line_number":31,"context_line":"elected for the cold migration, and if by chance the migration is failing, the"},{"line_number":32,"context_line":"compute node will call back conductor.migrate_server with the list of hosts"},{"line_number":33,"context_line":"minus itself so that conductor knows what to reschedule."},{"line_number":34,"context_line":"The stop condition is when the list is empty, we raise an Exception."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"},{"line_number":37,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_a9caaa6b","line":34,"in_reply_to":"1ae5cdf2_35236dbf","updated":"2014-06-26 13:04:03.000000000","message":"OK with the idea (providing retries to the conductor method), amending the blueprint.\n\nBtw, found a bug in the retry logic for booting an instance, it calls the old scheduler V2 API build_instance() which has been removed. Filing a ticket for it.","commit_id":"390d5537b61e999a4fe021664ae2f207fab2d3db"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"eb9049a481f0b616d982f801fa676efe883c6da1","unresolved":false,"context_lines":[{"line_number":31,"context_line":"elected for the cold migration, and if by chance the migration is failing, the"},{"line_number":32,"context_line":"compute node will call back conductor.migrate_server with the list of hosts"},{"line_number":33,"context_line":"minus itself so that conductor knows what to reschedule."},{"line_number":34,"context_line":"The stop condition is when the list is empty, we raise an Exception."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"},{"line_number":37,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ae5cdf2_35236dbf","line":34,"in_reply_to":"1ae5cdf2_6cad439b","updated":"2014-06-25 19:02:00.000000000","message":"This is kind of the same as booting an instance.  The conductor method that the compute/api calls and the method that the compute/manager calls on a reschedule are the same.  The big difference is passing around a list of hosts, which suffers from the issue you mentioned elsewhere of using stale data for a reschedule.\n\nHow about an alternate suggestion of not passing a list of hosts but passing a number of retries, or list of attempted hosts, and then rescheduling can happen in the conductor each time and retries can be limited via the new argument?","commit_id":"390d5537b61e999a4fe021664ae2f207fab2d3db"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"c5184b2d86e43b7fd8b7ef0b9e183b66af0376b7","unresolved":false,"context_lines":[{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"},{"line_number":31,"context_line":"by calling scheduler.utils.populate_retries before issuing select_destinations"},{"line_number":32,"context_line":"in conductor._cold_migrate and call back conductor.migrate_server instead of"},{"line_number":33,"context_line":"scheduler.prep_resize in the compute prep_resize method."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1ae5cdf2_112573ad","line":33,"updated":"2014-06-26 21:09:07.000000000","message":"This is a nice approach.  But this means that resize retries are limited to the same number as boot retries.  I went looking through the code and I didn\u0027t find where resize retries are limited currently.  Am I just missing something?","commit_id":"ec67644f90b8a30e57c7a7ee579bcd410684be4e"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c0cf13cfcce65c780bf93a0835dc18666b8cad6e","unresolved":false,"context_lines":[{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"},{"line_number":31,"context_line":"by calling scheduler.utils.populate_retries before issuing select_destinations"},{"line_number":32,"context_line":"in conductor._cold_migrate and call back conductor.migrate_server instead of"},{"line_number":33,"context_line":"scheduler.prep_resize in the compute prep_resize method."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1ae5cdf2_80868163","line":33,"in_reply_to":"1ae5cdf2_112573ad","updated":"2014-06-27 08:20:16.000000000","message":"https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L36\n\nWell I propose to keep the same values for consistency over booting and resize logics, as Phil raised in his last comment.\nWe also don\u0027t need to create another code, just to make use of an existing one :-)","commit_id":"ec67644f90b8a30e57c7a7ee579bcd410684be4e"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"1b77a5a8ac7a511ff2f450b4de3fabb6fe1726d8","unresolved":false,"context_lines":[{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"},{"line_number":31,"context_line":"by calling scheduler.utils.populate_retries before issuing select_destinations"},{"line_number":32,"context_line":"in conductor._cold_migrate and call back conductor.migrate_server instead of"},{"line_number":33,"context_line":"scheduler.prep_resize in the compute prep_resize method."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"baada198_2c31eb0b","line":33,"in_reply_to":"1ae5cdf2_80868163","updated":"2014-06-30 16:12:47.000000000","message":"Where are resize attempts currently enforced?  I didn\u0027t see anywhere that they are currently.","commit_id":"ec67644f90b8a30e57c7a7ee579bcd410684be4e"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"87f12f6e8f06309dc46f23a2bbf86e6264b64b7d","unresolved":false,"context_lines":[{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"},{"line_number":31,"context_line":"by calling scheduler.utils.populate_retries before issuing select_destinations"},{"line_number":32,"context_line":"in conductor._cold_migrate and call back conductor.migrate_server instead of"},{"line_number":33,"context_line":"scheduler.prep_resize in the compute prep_resize method."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"baada198_875d70ec","line":33,"in_reply_to":"baada198_2c31eb0b","updated":"2014-06-30 16:23:12.000000000","message":"Maybe you missed it, or I misunderstood ? \nhttps://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L161","commit_id":"ec67644f90b8a30e57c7a7ee579bcd410684be4e"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"b792b64903e83b68192ff1dff8a612ee03d3aecf","unresolved":false,"context_lines":[{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"},{"line_number":31,"context_line":"by calling scheduler.utils.populate_retries before issuing select_destinations"},{"line_number":32,"context_line":"in conductor._cold_migrate and call back conductor.migrate_server instead of"},{"line_number":33,"context_line":"scheduler.prep_resize in the compute prep_resize method."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"baada198_92884ce9","line":33,"in_reply_to":"baada198_875d70ec","updated":"2014-06-30 16:56:14.000000000","message":"Currently there don\u0027t appear to be any limitations on the maximum number of reschedules for a resize.  By adding this in I think you\u0027re creating a deployer impact that needs to be documented below.","commit_id":"ec67644f90b8a30e57c7a7ee579bcd410684be4e"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"b792b64903e83b68192ff1dff8a612ee03d3aecf","unresolved":false,"context_lines":[{"line_number":77,"context_line":"Other deployer impact"},{"line_number":78,"context_line":"---------------------"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"None"},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Developer impact"},{"line_number":83,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"baada198_925f6c72","line":80,"updated":"2014-06-30 16:56:14.000000000","message":"resize would now be honoring the \u0027max_scheduler_attempts\u0027 config flag which is a change in behaviour that deployers should be aware of.","commit_id":"ec67644f90b8a30e57c7a7ee579bcd410684be4e"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"32d954357be26050ea89e7f9b5669b48a80a3024","unresolved":false,"context_lines":[{"line_number":24,"context_line":"by calling scheduler.prep_resize(), which itself calls compute.prep_resize()"},{"line_number":25,"context_line":"after issuing a select_destinations()."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Proposed change"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"}],"source_content_type":"text/x-rst","patch_set":7,"id":"baada198_c2519637","line":27,"updated":"2014-07-03 13:11:43.000000000","message":"This seems like two distinct changes and I would prefer them to be split into two specs for clarity.  1. Change compute to call conductor.migrate_server for rescheduling, 2. Add retry limitation logic to conductor._cold_migrate.  Right now the proposed change is overreaching the problem description which is only concerned with not calling the scheduler.prep_resize method.\n\nI\u0027m in favor of both changes that you\u0027re proposing here but I think they should be discussed and documented separately.  It would be easy for someone to overlook the retry change in here if they\u0027re skimming specs to see what changes are planned for Juno.","commit_id":"ea4b886a161a9b587edfc1e54ce1cc9456f18c99"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fc30e99629185ad676b6f2a3da2c23e37b42d59c","unresolved":false,"context_lines":[{"line_number":24,"context_line":"by calling scheduler.prep_resize(), which itself calls compute.prep_resize()"},{"line_number":25,"context_line":"after issuing a select_destinations()."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Proposed change"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"}],"source_content_type":"text/x-rst","patch_set":7,"id":"baada198_b05cc14c","line":27,"in_reply_to":"baada198_c2519637","updated":"2014-07-04 11:36:46.000000000","message":"As per your below commit, will just provide a change for only moving the call to conductor instead of scheduler","commit_id":"ea4b886a161a9b587edfc1e54ce1cc9456f18c99"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"784866c6a18484523bb7ee67dd182ac2b912501f","unresolved":false,"context_lines":[{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"},{"line_number":31,"context_line":"by calling scheduler.utils.populate_retries before issuing select_destinations"},{"line_number":32,"context_line":"in conductor._cold_migrate and call back conductor.migrate_server instead of"},{"line_number":33,"context_line":"scheduler.prep_resize in the compute prep_resize method."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":7,"id":"baada198_cfbd3eb9","line":33,"updated":"2014-07-03 13:44:35.000000000","message":"I just saw https://review.openstack.org/#/c/98036/ which addresses the retry issue.  And after doing some research it appears that not limiting retries is a regression.  So the retry issue is moot now.","commit_id":"ea4b886a161a9b587edfc1e54ce1cc9456f18c99"},{"author":{"_account_id":5441,"name":"Andrew Laski","email":"andrew@lascii.com","username":"alaski"},"change_message_id":"7733bf5b85f40e4b39d5ffbd47ec1df28dbd9552","unresolved":false,"context_lines":[{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"},{"line_number":31,"context_line":"by calling scheduler.utils.populate_retries before issuing select_destinations"},{"line_number":32,"context_line":"in conductor._cold_migrate and call back conductor.migrate_server instead of"},{"line_number":33,"context_line":"scheduler.prep_resize in the compute prep_resize method."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":7,"id":"baada198_3b577f27","line":33,"in_reply_to":"baada198_50428568","updated":"2014-07-07 17:26:21.000000000","message":"If it was new functionality it would need a spec.  But the functionality existed before and was lost in a refactor, so adding it back was a bug fix rather than adding something new.","commit_id":"ea4b886a161a9b587edfc1e54ce1cc9456f18c99"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fc30e99629185ad676b6f2a3da2c23e37b42d59c","unresolved":false,"context_lines":[{"line_number":30,"context_line":"The idea is to provide the number of retries a migration is currently facing"},{"line_number":31,"context_line":"by calling scheduler.utils.populate_retries before issuing select_destinations"},{"line_number":32,"context_line":"in conductor._cold_migrate and call back conductor.migrate_server instead of"},{"line_number":33,"context_line":"scheduler.prep_resize in the compute prep_resize method."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":7,"id":"baada198_50428568","line":33,"in_reply_to":"baada198_cfbd3eb9","updated":"2014-07-04 11:36:46.000000000","message":"Ok, thanks for it, I was unaware of this one. \n\nJust wondering why such a change imapcting operators was not asked to be defined by a spec ?","commit_id":"ea4b886a161a9b587edfc1e54ce1cc9456f18c99"}]}