)]}'
{"specs/newton/ha-aa-job-distribution.rst":[{"author":{"_account_id":6491,"name":"xing-yang","email":"xingyang105@gmail.com","username":"xing-yang"},"change_message_id":"187e97f090c1374a943a645dc846fe7611c8c955","unresolved":false,"context_lines":[{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Services will keep reporting their heartbeats in the same way that they are"},{"line_number":124,"context_line":"doing it now, and it will be Scheduler\u0027s job to separate between individual and"},{"line_number":125,"context_line":"clustered hosts and aggregate the latter by cluster name."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"As explained in `REST API impact`_ the API will be able to show cluster"},{"line_number":128,"context_line":"information with the status -up or down- of each cluster based on the hosts"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7aa08908_95a9cd92","line":125,"updated":"2016-06-14 15:32:34.000000000","message":"So the scheduler will send a message with one topic which is either individual host based on cluster based?","commit_id":"38699c0415db7af2113fe69e39883923ec08f1a7"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"23c362de32caa2dc4dd90a70d2ce0b77dcc58b13","unresolved":false,"context_lines":[{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Services will keep reporting their heartbeats in the same way that they are"},{"line_number":124,"context_line":"doing it now, and it will be Scheduler\u0027s job to separate between individual and"},{"line_number":125,"context_line":"clustered hosts and aggregate the latter by cluster name."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"As explained in `REST API impact`_ the API will be able to show cluster"},{"line_number":128,"context_line":"information with the status -up or down- of each cluster based on the hosts"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3aaa91ec_a09f42b3","line":125,"in_reply_to":"7aa08908_95a9cd92","updated":"2016-06-21 17:20:52.000000000","message":"Yes, that is correct.  It is the same as other RPC calls will be doing [1], but in the case of creation the receiving node will have to add the host field itself since the scheduler will only have added the cluster_name field.\n\n[1]: https://review.openstack.org/#/c/318573/5/cinder/volume/rpcapi.py@118","commit_id":"38699c0415db7af2113fe69e39883923ec08f1a7"},{"author":{"_account_id":6491,"name":"xing-yang","email":"xingyang105@gmail.com","username":"xing-yang"},"change_message_id":"187e97f090c1374a943a645dc846fe7611c8c955","unresolved":false,"context_lines":[{"line_number":265,"context_line":"- ``race_preventer``: This field will be used to prevent potential races that"},{"line_number":266,"context_line":"                      could happen if 2 new services are brought up at the same"},{"line_number":267,"context_line":"                      time and both try to create the cluster entry at the same"},{"line_number":268,"context_line":"                      time."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"A ``cluster_name`` field will be added to existing ``services``, ``volumes``,"},{"line_number":271,"context_line":"and ``consistencygroups`` tables."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7aa08908_95b42d82","line":268,"updated":"2016-06-14 15:32:34.000000000","message":"How does this work?  Is this a string or something else?  Please clarify.","commit_id":"38699c0415db7af2113fe69e39883923ec08f1a7"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"23c362de32caa2dc4dd90a70d2ce0b77dcc58b13","unresolved":false,"context_lines":[{"line_number":265,"context_line":"- ``race_preventer``: This field will be used to prevent potential races that"},{"line_number":266,"context_line":"                      could happen if 2 new services are brought up at the same"},{"line_number":267,"context_line":"                      time and both try to create the cluster entry at the same"},{"line_number":268,"context_line":"                      time."},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"A ``cluster_name`` field will be added to existing ``services``, ``volumes``,"},{"line_number":271,"context_line":"and ``consistencygroups`` tables."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3aaa91ec_403adece","line":268,"in_reply_to":"7aa08908_95b42d82","updated":"2016-06-21 17:20:52.000000000","message":"I\u0027d rather not clutter the specs with too many implementation details, unless you think it is really helpful, but there\u0027s an explanation on the code: https://review.openstack.org/#/c/318572/5/cinder/db/sqlalchemy/models.py@106","commit_id":"38699c0415db7af2113fe69e39883923ec08f1a7"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"8ba58704c0db9f8270e3d7dc1864fd064c8eb563","unresolved":false,"context_lines":[{"line_number":134,"context_line":"This new mechanism will change the \"service unit\" from service to cluster for"},{"line_number":135,"context_line":"services that are in a cluster.  Which means that once all operations have been"},{"line_number":136,"context_line":"moved to support Active-Active configurations we won\u0027t be able to disable an"},{"line_number":137,"context_line":"individual service belonging to a cluster and we\u0027ll have to disable the cluster"},{"line_number":138,"context_line":"itself."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Disabling a cluster will prevent schedulers from taking that cluster, and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aa78d24_5c4964cf","line":137,"updated":"2016-07-07 02:49:02.000000000","message":"....the *entire* cluster itself ?","commit_id":"57506e7a636febcd0709b131c9829f1a5e244f46"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"ee3878d2ed284380403d37dd71a8875a7571274c","unresolved":false,"context_lines":[{"line_number":134,"context_line":"This new mechanism will change the \"service unit\" from service to cluster for"},{"line_number":135,"context_line":"services that are in a cluster.  Which means that once all operations have been"},{"line_number":136,"context_line":"moved to support Active-Active configurations we won\u0027t be able to disable an"},{"line_number":137,"context_line":"individual service belonging to a cluster and we\u0027ll have to disable the cluster"},{"line_number":138,"context_line":"itself."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"Disabling a cluster will prevent schedulers from taking that cluster, and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aa78d24_9d561404","line":137,"in_reply_to":"1aa78d24_5c4964cf","updated":"2016-07-07 11:38:54.000000000","message":"Yes, that\u0027s correct.","commit_id":"57506e7a636febcd0709b131c9829f1a5e244f46"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"8ba58704c0db9f8270e3d7dc1864fd064c8eb563","unresolved":false,"context_lines":[{"line_number":145,"context_line":"It stands to reason that sometimes we\u0027ll need to drain nodes to remove them"},{"line_number":146,"context_line":"from a cluster, but this spec and its implementation will not be adding any new"},{"line_number":147,"context_line":"mechanism for that.  So existing mechanism should be used to perform graceful"},{"line_number":148,"context_line":"shutdown of cinder volume services."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Current graceful shutdown mechanism will make sure that no new operations are"},{"line_number":151,"context_line":"received from the AMQP queue while it waits for ongoing operations to complete"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aa78d24_5c77a401","line":148,"updated":"2016-07-07 02:49:02.000000000","message":"so we can\u0027t disable a single node in the cluster?   This sort of defeats one of the tenants of having A/A.   One of the reasons for desiring A/A is  so that we can have the service up and take one of the nodes down for maintenance.","commit_id":"57506e7a636febcd0709b131c9829f1a5e244f46"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"53f5e75a7473898b60a5e883c9ec84ccb5591e54","unresolved":false,"context_lines":[{"line_number":145,"context_line":"It stands to reason that sometimes we\u0027ll need to drain nodes to remove them"},{"line_number":146,"context_line":"from a cluster, but this spec and its implementation will not be adding any new"},{"line_number":147,"context_line":"mechanism for that.  So existing mechanism should be used to perform graceful"},{"line_number":148,"context_line":"shutdown of cinder volume services."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Current graceful shutdown mechanism will make sure that no new operations are"},{"line_number":151,"context_line":"received from the AMQP queue while it waits for ongoing operations to complete"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aa78d24_1792e156","line":148,"in_reply_to":"1aa78d24_351efd0b","updated":"2016-07-13 17:10:55.000000000","message":"Done","commit_id":"57506e7a636febcd0709b131c9829f1a5e244f46"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"ee3878d2ed284380403d37dd71a8875a7571274c","unresolved":false,"context_lines":[{"line_number":145,"context_line":"It stands to reason that sometimes we\u0027ll need to drain nodes to remove them"},{"line_number":146,"context_line":"from a cluster, but this spec and its implementation will not be adding any new"},{"line_number":147,"context_line":"mechanism for that.  So existing mechanism should be used to perform graceful"},{"line_number":148,"context_line":"shutdown of cinder volume services."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Current graceful shutdown mechanism will make sure that no new operations are"},{"line_number":151,"context_line":"received from the AMQP queue while it waits for ongoing operations to complete"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aa78d24_fd48f8b4","line":148,"in_reply_to":"1aa78d24_5c77a401","updated":"2016-07-07 11:38:54.000000000","message":"DuncanT also raised this question in the original specs (this is just an update with changes from the Austin Summit) and it was agreed that disabling individual services in a cluster was not necessary as you could just stop the service itself to take down the node for maintenance.  After all, disabling only takes out the scheduler path, not the c-api to c-vol path.\n\nI\u0027ll see what would it take to allow disabling individual hosts from clusters in the scheduling decisions, and if it\u0027s acceptable I\u0027ll amend the specs and add it to the code.","commit_id":"57506e7a636febcd0709b131c9829f1a5e244f46"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"e0604b8814145c3ac553de3810d886b6b2b5381a","unresolved":false,"context_lines":[{"line_number":145,"context_line":"It stands to reason that sometimes we\u0027ll need to drain nodes to remove them"},{"line_number":146,"context_line":"from a cluster, but this spec and its implementation will not be adding any new"},{"line_number":147,"context_line":"mechanism for that.  So existing mechanism should be used to perform graceful"},{"line_number":148,"context_line":"shutdown of cinder volume services."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Current graceful shutdown mechanism will make sure that no new operations are"},{"line_number":151,"context_line":"received from the AMQP queue while it waits for ongoing operations to complete"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aa78d24_1243176d","line":148,"in_reply_to":"1aa78d24_fd48f8b4","updated":"2016-07-07 18:25:33.000000000","message":"Ok, after studying a way to do this, it would take quite some work because we would have to add yet another topic queue to segregate communications coming from the scheduler and then making volume services stop listening to that topic queue on disabling and begin listening when re-enabled.\n\nIf this is something we really, really want we can have it after everything else is done, but at this point I think this will greatly derail us since this is not a trivial task.","commit_id":"57506e7a636febcd0709b131c9829f1a5e244f46"},{"author":{"_account_id":5997,"name":"Walt","display_name":"Hemna","email":"waboring@hemna.com","username":"walter-boring","status":"SAP"},"change_message_id":"441adc2227b16f807bc85c912608eef4c788d936","unresolved":false,"context_lines":[{"line_number":145,"context_line":"It stands to reason that sometimes we\u0027ll need to drain nodes to remove them"},{"line_number":146,"context_line":"from a cluster, but this spec and its implementation will not be adding any new"},{"line_number":147,"context_line":"mechanism for that.  So existing mechanism should be used to perform graceful"},{"line_number":148,"context_line":"shutdown of cinder volume services."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Current graceful shutdown mechanism will make sure that no new operations are"},{"line_number":151,"context_line":"received from the AMQP queue while it waits for ongoing operations to complete"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aa78d24_351efd0b","line":148,"in_reply_to":"1aa78d24_fd48f8b4","updated":"2016-07-07 18:27:41.000000000","message":"So, since this has come up a few times in the specs, then I would suggest documenting the process here, as it\u0027s relevant to the spec.  If we document in the spec as well as a devref how to disable a specific node, then I\u0027d be ok with this.","commit_id":"57506e7a636febcd0709b131c9829f1a5e244f46"},{"author":{"_account_id":20140,"name":"Karthik Prabhu Vinod","email":"karthik.prabhu.vinod@intel.com","username":"kprabhuv"},"change_message_id":"5c4af7fc6b54a9e9626a1a6e2fd5d74084d3bf4a","unresolved":false,"context_lines":[{"line_number":166,"context_line":""},{"line_number":167,"context_line":"In a similar way to the Service state reporting we need to prevent concurrent"},{"line_number":168,"context_line":"access to the data structure when updating this information. Fortunately for us"},{"line_number":169,"context_line":"we are storing this information in a Python dictionary on the schedulers, and"},{"line_number":170,"context_line":"since we are using an eventlet executor for the RPC server we don’t have to"},{"line_number":171,"context_line":"worry about using locks, the inherent behavior of the executor will prevent"},{"line_number":172,"context_line":"concurrent access to the dictionary.  So no changes are needed there to have"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aa78d24_314a0d84","line":169,"range":{"start_line":169,"start_character":44,"end_line":169,"end_character":54},"updated":"2016-07-11 16:15:52.000000000","message":"We are turning this dict into ovo to support rolling upgrades. I am not sure how this affects eventlet executor. We may have to think about using locks if we plan to go ahead with turning service capabilities into ovo!!","commit_id":"57506e7a636febcd0709b131c9829f1a5e244f46"},{"author":{"_account_id":9535,"name":"Gorka Eguileor","email":"geguileo@redhat.com","username":"Gorka"},"change_message_id":"53f5e75a7473898b60a5e883c9ec84ccb5591e54","unresolved":false,"context_lines":[{"line_number":166,"context_line":""},{"line_number":167,"context_line":"In a similar way to the Service state reporting we need to prevent concurrent"},{"line_number":168,"context_line":"access to the data structure when updating this information. Fortunately for us"},{"line_number":169,"context_line":"we are storing this information in a Python dictionary on the schedulers, and"},{"line_number":170,"context_line":"since we are using an eventlet executor for the RPC server we don’t have to"},{"line_number":171,"context_line":"worry about using locks, the inherent behavior of the executor will prevent"},{"line_number":172,"context_line":"concurrent access to the dictionary.  So no changes are needed there to have"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1aa78d24_f7b11502","line":169,"range":{"start_line":169,"start_character":44,"end_line":169,"end_character":54},"in_reply_to":"1aa78d24_314a0d84","updated":"2016-07-13 17:10:55.000000000","message":"In that case we may need to use @lockutils.synchronized method to make sure only 1 is changing it at a time.","commit_id":"57506e7a636febcd0709b131c9829f1a5e244f46"}]}