)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"4cdd072047656f4b93e87bd1e1c0b5e2ee6e766e","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     EdLeafe \u003ced@leafe.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2015-01-21 23:22:36 +0000"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Remove direct nova DB/API access by Scheduler Filters"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Some filters need information about the current instances on a host in"},{"line_number":10,"context_line":"order to make their decisions. Currently they get their filtering"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":14,"id":"1a930d6b_fe93b6f7","line":7,"updated":"2015-01-22 21:40:19.000000000","message":"Could you please match the title of this commit with the title of your spec ?","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"0b776788fe2dff30f370950dd09ba2ffbbf160fc","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     EdLeafe \u003ced@leafe.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2015-01-21 23:22:36 +0000"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Remove direct nova DB/API access by Scheduler Filters"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Some filters need information about the current instances on a host in"},{"line_number":10,"context_line":"order to make their decisions. Currently they get their filtering"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":14,"id":"1a930d6b_01fd873a","line":7,"in_reply_to":"1a930d6b_fe93b6f7","updated":"2015-01-22 22:17:44.000000000","message":"Sure, if it\u0027s that important. Done.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"}],"specs/kilo/approved/isolate-scheduler-db-filters.rst":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"972ad8572ddcb7b25379f3452bfa3bce6b26e460","unresolved":false,"context_lines":[{"line_number":51,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Replace the db/api calls with the corresponding nova object calls; e.g.: use"},{"line_number":54,"context_line":"`objects.InstanceList.get_all` instead of `db.instance_get_all`."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_cadc2b77","line":54,"updated":"2014-12-03 08:53:42.000000000","message":"Well, the problem is that we don\u0027t except to store the Instances table in the scheduler once we\u0027ll split (like the Aggregates table too). Scheduler should only look at HostState indeally for knowing the status.","commit_id":"733dfe4acbd46fd5f06406acfc5a44597f637989"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"36f268f12fe4729e9c727c85ee07ea3ba7d03d48","unresolved":false,"context_lines":[{"line_number":51,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Replace the db/api calls with the corresponding nova object calls; e.g.: use"},{"line_number":54,"context_line":"`objects.InstanceList.get_all` instead of `db.instance_get_all`."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a890539_deb77f83","line":54,"in_reply_to":"5a890539_cadc2b77","updated":"2014-12-03 15:43:01.000000000","message":"Ah, ok. I thought we were doing it in two steps: objects first, then HostState updates. I\u0027ll change the spec accordingly.","commit_id":"733dfe4acbd46fd5f06406acfc5a44597f637989"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fa7938399affefbe71cab2eaa1f7f9cc599f3f2","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Isolate Scheduler DB for Filters"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/isolate-scheduler-db"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_552eaeac","line":8,"updated":"2014-12-05 15:35:34.000000000","message":"the naming is incorrect, it should be isolate-sched-db for Instances","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"6d339ef1257200ce7eee75028b019f578c8604f7","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"The scheduler currently directly accesses the nova db, either by calling the db"},{"line_number":23,"context_line":"module directly, or by calling the nova compute API, which prevents it from"},{"line_number":24,"context_line":"being separated as an indpendent service. There are three filters that need"},{"line_number":25,"context_line":"updating:"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"* TypeAffinityFilter"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a961159_bb272c11","line":24,"updated":"2014-12-11 22:18:27.000000000","message":"s/indpendent/independent/","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fa7938399affefbe71cab2eaa1f7f9cc599f3f2","unresolved":false,"context_lines":[{"line_number":30,"context_line":""},{"line_number":31,"context_line":"These filters need to be updated to use HostState objects in the scheduler"},{"line_number":32,"context_line":"instead of accessing the db directly or calling the nova compute API."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Use Cases"},{"line_number":36,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_d521beb6","line":33,"updated":"2014-12-05 15:35:34.000000000","message":"IMHO, you should mention the aggregates BP by saying that the BP you\u0027re working on is part of a global effort about modifying accesses for filters","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fa7938399affefbe71cab2eaa1f7f9cc599f3f2","unresolved":false,"context_lines":[{"line_number":44,"context_line":"-----------------"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"This blueprint is part of the \u0027scheduler\u0027 refactoring effort, defined as a 3rd"},{"line_number":47,"context_line":"priority for the Kilo release."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_3529229c","line":47,"updated":"2014-12-05 15:35:34.000000000","message":"I finally just left the mention of a \u0027priority\u0027, not the rank.","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"6d339ef1257200ce7eee75028b019f578c8604f7","unresolved":false,"context_lines":[{"line_number":55,"context_line":"In order for that to work, the Scheduler client will need a new method with the"},{"line_number":56,"context_line":"following structure:"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"    update_host_instances(context, instance, action)"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"This method will be called by a compute node whenever there is a change in its"},{"line_number":61,"context_line":"instances that would affect filtering decisions, such as create/delete/resize."}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a961159_db24f80e","line":58,"updated":"2014-12-11 22:18:27.000000000","message":"How is this different from the current scheduler client\u0027s update_resource_stats() method, which is given the compute node\u0027s most up-to-date view of resource consumption and the scheduler uses to update compute node records in the database? Couldn\u0027t the list of instances housed on a compute node be supplied in the information already sent to the scheduler in the update_resource_stats() method?\n\nAlternately, instead of a large packet of information like the parameters passed in update_resource_stats(), we could have more fine-grained status notifications that the scheduler subscribes to, but I honestly think that is something we can do in a later version of the scheduler API once it is split out into Gantt and we properly version a REST API.","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"6d339ef1257200ce7eee75028b019f578c8604f7","unresolved":false,"context_lines":[{"line_number":64,"context_line":"would then update the corresponding HostState object. In the case of an"},{"line_number":65,"context_line":"instance being deleted, only its UUID would need to be passed. The HostState"},{"line_number":66,"context_line":"object would store these objects in a new `instances` attribute, which would be"},{"line_number":67,"context_line":"a dict with the UUID as the key, and the Instance object as the value."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":70,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a961159_fb1d34bf","line":67,"updated":"2014-12-11 22:18:27.000000000","message":"@Sylvain, I actually don\u0027t think you are correct about finer-grained notifications not scaling as well as the existing coarse-grained update_resource_stats() method, which is called every time anything changes on the compute node and contains all of the resource information for the entire compute node, instead of just the little bit that changed. Regardless, I don\u0027t think we should change the architecture of the scheduler\u0027s update_resource_stats() method in this blueprint.\n\n@Dan: But, the scheduler already does exactly that: each time a compute node is updated with a new or deleted or changed instance, the compute node calls update_resource_stats() on the scheduler client which updates the compute_nodes table with all the compute node\u0027s updated resource information.","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fa7938399affefbe71cab2eaa1f7f9cc599f3f2","unresolved":false,"context_lines":[{"line_number":64,"context_line":"would then update the corresponding HostState object. In the case of an"},{"line_number":65,"context_line":"instance being deleted, only its UUID would need to be passed. The HostState"},{"line_number":66,"context_line":"object would store these objects in a new `instances` attribute, which would be"},{"line_number":67,"context_line":"a dict with the UUID as the key, and the Instance object as the value."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":70,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_d00f0c2e","line":67,"updated":"2014-12-05 15:35:34.000000000","message":"As discussed per IRC, this approach doesn\u0027t scale because the scheduler will scale per number of instances instead of per requests\n\nSee my updated spec for aggregates as the explanation","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1a3549768f93c42eb7806eac85174c23fa5a2bff","unresolved":false,"context_lines":[{"line_number":64,"context_line":"would then update the corresponding HostState object. In the case of an"},{"line_number":65,"context_line":"instance being deleted, only its UUID would need to be passed. The HostState"},{"line_number":66,"context_line":"object would store these objects in a new `instances` attribute, which would be"},{"line_number":67,"context_line":"a dict with the UUID as the key, and the Instance object as the value."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":70,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a961159_a9618dd4","line":67,"in_reply_to":"3a961159_fb1d34bf","updated":"2014-12-12 15:53:57.000000000","message":"Okay, I thought it just went to the database directly, but I traced it out and see now.","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f4dc216d56810a3f58990e238c68a5f5972ec374","unresolved":false,"context_lines":[{"line_number":64,"context_line":"would then update the corresponding HostState object. In the case of an"},{"line_number":65,"context_line":"instance being deleted, only its UUID would need to be passed. The HostState"},{"line_number":66,"context_line":"object would store these objects in a new `instances` attribute, which would be"},{"line_number":67,"context_line":"a dict with the UUID as the key, and the Instance object as the value."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":70,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_2612c809","line":67,"in_reply_to":"5a890539_d00f0c2e","updated":"2014-12-05 23:28:07.000000000","message":"It seems flawed to contact the scheduler every time something changes on the compute node. The scheduler in large deployments is already overwhelmed with scheduling new instances, right?\n\nI\u0027m also concerned by the statement \"called by the compute node whenever there is a change in its instances that would affect filtering decisions\". Do you just mean create/delete/resize or potentially others that could affect any filter? Shouldn\u0027t the scheduler already be completely aware of create/delete operations? Some resizes (by admins, without scheduler intervention) would be unknown, but otherwise, I\u0027m not sure I understand.","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"6d339ef1257200ce7eee75028b019f578c8604f7","unresolved":false,"context_lines":[{"line_number":65,"context_line":"instance being deleted, only its UUID would need to be passed. The HostState"},{"line_number":66,"context_line":"object would store these objects in a new `instances` attribute, which would be"},{"line_number":67,"context_line":"a dict with the UUID as the key, and the Instance object as the value."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":70,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"},{"line_number":71,"context_line":"reasons:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a961159_1b1be0ca","line":68,"updated":"2014-12-11 22:18:27.000000000","message":"@Sylvain: I really would be opposed to putting a relation between compute_nodes table and instances table. That goes against the current push to segregate the Nova database calls within the scheduler.","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9fa7938399affefbe71cab2eaa1f7f9cc599f3f2","unresolved":false,"context_lines":[{"line_number":65,"context_line":"instance being deleted, only its UUID would need to be passed. The HostState"},{"line_number":66,"context_line":"object would store these objects in a new `instances` attribute, which would be"},{"line_number":67,"context_line":"a dict with the UUID as the key, and the Instance object as the value."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":70,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"},{"line_number":71,"context_line":"reasons:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_704f386b","line":68,"updated":"2014-12-05 15:35:34.000000000","message":"By thinking about this problem, I think it would be feasible to extend the compute_nodes table by adding a relationship on a list of instances, extending the existing HostState and provide calls thru the scheduler.client to compute_nodes","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"42348181fbe544bc8d0021e1e297e02d260edc72","unresolved":false,"context_lines":[{"line_number":65,"context_line":"instance being deleted, only its UUID would need to be passed. The HostState"},{"line_number":66,"context_line":"object would store these objects in a new `instances` attribute, which would be"},{"line_number":67,"context_line":"a dict with the UUID as the key, and the Instance object as the value."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":70,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"},{"line_number":71,"context_line":"reasons:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_65aa0a1c","line":68,"in_reply_to":"5a890539_5845fe41","updated":"2014-12-05 21:25:20.000000000","message":"Well, the difference is that the Instances table is owned by Nova and can\u0027t easily be only for the Scheduler ;)\n\nSee really my implementation proposal and the alternatives, you\u0027ll see that we need to create some duplication.","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"9f486128dce1d7da9284631c632e6abeaeeba4c0","unresolved":false,"context_lines":[{"line_number":65,"context_line":"instance being deleted, only its UUID would need to be passed. The HostState"},{"line_number":66,"context_line":"object would store these objects in a new `instances` attribute, which would be"},{"line_number":67,"context_line":"a dict with the UUID as the key, and the Instance object as the value."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":70,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"},{"line_number":71,"context_line":"reasons:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5a890539_5845fe41","line":68,"in_reply_to":"5a890539_704f386b","updated":"2014-12-05 17:35:39.000000000","message":"How different is this than my original approach, which was to add the method objects.InstanceList.get_uuids_by_host(), and use that in the filter?","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"6d339ef1257200ce7eee75028b019f578c8604f7","unresolved":false,"context_lines":[{"line_number":84,"context_line":"    `set([inst.instance_type_id for inst in host_state.instances.values()])`"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"The filters could then be changed to only use the HostState object\u0027s"},{"line_number":87,"context_line":"`instances` attribute, instead of making db/api calls."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3a961159_3b7b3cf6","line":87,"updated":"2014-12-11 22:18:27.000000000","message":"This is exactly correct. ++.","commit_id":"8cb736c484943086dc6be74da434fa40dae82055"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e092512b4c97b7a88970a015d74187f36ee3cbce","unresolved":false,"context_lines":[{"line_number":29,"context_line":"* DifferentHostFilter"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"These filters need to be updated to use HostState objects in the scheduler"},{"line_number":32,"context_line":"instead of accessing the db directly or calling the nova compute API."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3a961159_6b56562c","line":32,"updated":"2014-12-29 17:08:55.000000000","message":"++","commit_id":"f4e05f8d7d5871985aa163dad4bdbae37eb9a2b8"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e092512b4c97b7a88970a015d74187f36ee3cbce","unresolved":false,"context_lines":[{"line_number":86,"context_line":"containing full Instance objects, so that any additional filters that needed to"},{"line_number":87,"context_line":"use instance information to do their filtering could be added without changing"},{"line_number":88,"context_line":"any code, but that was generally felt to be too \u0027heavy\u0027 for something that may"},{"line_number":89,"context_line":"or may not come to pass."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Once this field is added to ComputeNode, and the changeset to objectify"},{"line_number":92,"context_line":"`compute_node_get_all()` is merged, the filters will be modified to get the"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3a961159_e607db16","line":89,"updated":"2014-12-29 17:08:55.000000000","message":"This is my preference. Add a new field to nova.objects.ComputeNode called \"instances\" that is of type nova.objects.fields.ListOfObjectField(\u0027Instance\u0027) and just be done with it. It would be lazy-loaded (if ever loaded at all instead of being set manually by the resource tracker when it sends the update_resource_stats() call parameters.)\n\nYes, this approach means that the memory footprint of each scheduler process will be bigger, but we should not prematurely optimize our calling interfaces to be memory-efficient. Pass the entire set of objects in update_resource_stats() and deal with making the server-side memory cache of compute node objects more efficient if need be with incremental improvement. I\u0027d rather have all the instance information sent in an Instance object than constantly having to change the structure of the ComputeNode object each time the scheduler decides it wants to operate on some piece of instance information other than the instance type ID...","commit_id":"f4e05f8d7d5871985aa163dad4bdbae37eb9a2b8"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e092512b4c97b7a88970a015d74187f36ee3cbce","unresolved":false,"context_lines":[{"line_number":105,"context_line":"favored, as it would be very \u0027chatty\u0027, since each change to an instance would"},{"line_number":106,"context_line":"have to be broadcast to each Scheduler. It would also be relatively fragile, as"},{"line_number":107,"context_line":"it would require code changes to every place in the code base where an instance"},{"line_number":108,"context_line":"could be modified. Since the Scheduler already creates a full list of hosts"},{"line_number":109,"context_line":"with each request, the changes needed to accomodate this would be localized to"},{"line_number":110,"context_line":"a single part of the code."},{"line_number":111,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3a961159_6653ebe2","line":108,"updated":"2014-12-29 17:08:55.000000000","message":"I don\u0027t understand this rationale. We are already sending via the update_resource_stats() conductor RPC API method information about the resources on a compute node every time an instance action (boot, resize, terminate) is made. If we instead just sent the changed pieces of the compute node resources (including Instance objects that were acted upon) to the *scheduler* directly instead of to the conductor and then have the scheduler continually re-read the compute node and instance list information from the conductor on each call to select_destinations(), the system as a whole would be much more efficient.","commit_id":"f4e05f8d7d5871985aa163dad4bdbae37eb9a2b8"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fdd565553d9def658e5e96b6fdfad48b84ee80d1","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Isolate Scheduler DB for Filters"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/isolate-scheduler-db"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_4f3906f1","line":8,"updated":"2015-01-07 21:12:51.000000000","message":"s/Filters/Instances","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"74589e36cfac7c2a07d5490f72b69bfc55e1aa9c","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Isolate Scheduler DB for Filters"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/isolate-scheduler-db"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_f20fdcdd","line":8,"in_reply_to":"3a961159_4f3906f1","updated":"2015-01-08 16:18:09.000000000","message":"The focus of this is to make the filters that access the Nova DB work without that access. It\u0027s true that the proposed fix is to have Instances passed, but that is just one possible solution.","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"62c822f95fdf2179495818e7112feac9a83ba4f4","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Isolate Scheduler DB for Filters"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/isolate-scheduler-db"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_db68268a","line":8,"in_reply_to":"3a961159_f20fdcdd","updated":"2015-01-09 11:32:02.000000000","message":"No, you misunderstood the scope of this spec.\n\nWe need to isolate DB for all the filters, that\u0027s the role of the blueprint, but there are N specs per 1 BP and this one is focusing on how filters are accessing info related to instance\u0027 uuid and flavor","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fdd565553d9def658e5e96b6fdfad48b84ee80d1","unresolved":false,"context_lines":[{"line_number":30,"context_line":""},{"line_number":31,"context_line":"These filters need to be updated to use host state objects in the scheduler"},{"line_number":32,"context_line":"instead of accessing the db directly or calling the nova compute API."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Use Cases"},{"line_number":36,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_4f102659","line":33,"updated":"2015-01-07 21:12:51.000000000","message":"here, the problem is about accessing instances and flavors related to instances, maybe you should put a note on this.","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"74589e36cfac7c2a07d5490f72b69bfc55e1aa9c","unresolved":false,"context_lines":[{"line_number":30,"context_line":""},{"line_number":31,"context_line":"These filters need to be updated to use host state objects in the scheduler"},{"line_number":32,"context_line":"instead of accessing the db directly or calling the nova compute API."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Use Cases"},{"line_number":36,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_323b2439","line":33,"in_reply_to":"3a961159_4f102659","updated":"2015-01-08 16:18:09.000000000","message":"Done","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fdd565553d9def658e5e96b6fdfad48b84ee80d1","unresolved":false,"context_lines":[{"line_number":39,"context_line":"to break the scheduler out into the Gantt project. In order to do this"},{"line_number":40,"context_line":"effectively, the internal interfaces around the scheduler and its filters must"},{"line_number":41,"context_line":"be updated to remove direct DB or API calls."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"Project Priority"},{"line_number":44,"context_line":"-----------------"},{"line_number":45,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_2a04a813","line":42,"updated":"2015-01-07 21:12:51.000000000","message":"That\u0027s not really a use-case...","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"74589e36cfac7c2a07d5490f72b69bfc55e1aa9c","unresolved":false,"context_lines":[{"line_number":39,"context_line":"to break the scheduler out into the Gantt project. In order to do this"},{"line_number":40,"context_line":"effectively, the internal interfaces around the scheduler and its filters must"},{"line_number":41,"context_line":"be updated to remove direct DB or API calls."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"Project Priority"},{"line_number":44,"context_line":"-----------------"},{"line_number":45,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_521d10bd","line":42,"in_reply_to":"3a961159_2a04a813","updated":"2015-01-08 16:18:09.000000000","message":"Heh, well, I could just write N/A like you did. :)","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":1981,"name":"Don Dugger","email":"n0ano@n0ano.com","username":"n0ano"},"change_message_id":"c36aa2528faab08e905d8e03068eae5186aaa38e","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Rather than have the filters make DB or API calls, we will replace those calls"},{"line_number":54,"context_line":"with code that uses an in-memory view of the compute nodes and their instance"},{"line_number":55,"context_line":"information. This information would be populated initially when the Scheduler"},{"line_number":56,"context_line":"starts up, and would be updated by the compute service whenever a significant"},{"line_number":57,"context_line":"change happens to any of its instances (create/ destroy/ resize). The"},{"line_number":58,"context_line":"`update_resource_stats()` method of the ResourceTracker will be augmented to"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_c9088f93","line":55,"updated":"2015-01-07 23:50:55.000000000","message":"Rather than having code that uses the in-memory view of the compute nodes should we have the filters access this info via an API call to the scheduler?  Having said that, the filters are tightly coupled to the scheduler so an API might be overkill.  Maybe you should talk about this in the alternatives section.","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"74589e36cfac7c2a07d5490f72b69bfc55e1aa9c","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"Rather than have the filters make DB or API calls, we will replace those calls"},{"line_number":54,"context_line":"with code that uses an in-memory view of the compute nodes and their instance"},{"line_number":55,"context_line":"information. This information would be populated initially when the Scheduler"},{"line_number":56,"context_line":"starts up, and would be updated by the compute service whenever a significant"},{"line_number":57,"context_line":"change happens to any of its instances (create/ destroy/ resize). The"},{"line_number":58,"context_line":"`update_resource_stats()` method of the ResourceTracker will be augmented to"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_9261383b","line":55,"in_reply_to":"3a961159_c9088f93","updated":"2015-01-08 16:18:09.000000000","message":"The filters are already passed a host_state object; this should contain all the information about the host that the filter would need.","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"da58c3728150e47df748db69bf6199d678ea6569","unresolved":false,"context_lines":[{"line_number":57,"context_line":"change happens to any of its instances (create/ destroy/ resize). The"},{"line_number":58,"context_line":"`update_resource_stats()` method of the ResourceTracker will be augmented to"},{"line_number":59,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":60,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":61,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":62,"context_line":"on a host from this object instead of making DB / API calls for each host."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_1bb1f58e","line":60,"updated":"2015-01-08 06:36:50.000000000","message":"We should describe detail what fields of Instance object will be passed to scheduler. Is that all the fields? like info_cache/fault/security_groups, is it really useful?\n\nAnd this some like we will depend on Nova instance object. So how scheduler can handle the Instance obj data model changed after scheduler split out nova.\n\nOr we should define another data model in scheduler for instance info?","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"74589e36cfac7c2a07d5490f72b69bfc55e1aa9c","unresolved":false,"context_lines":[{"line_number":57,"context_line":"change happens to any of its instances (create/ destroy/ resize). The"},{"line_number":58,"context_line":"`update_resource_stats()` method of the ResourceTracker will be augmented to"},{"line_number":59,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":60,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":61,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":62,"context_line":"on a host from this object instead of making DB / API calls for each host."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3a961159_d2ce602c","line":60,"in_reply_to":"3a961159_1bb1f58e","updated":"2015-01-08 16:18:09.000000000","message":"The proposal is to pass the full InstanceList object, rather than trying to parse out just the required fields. See jaypipes\u0027 comment on PS 8 for why it is proposed this way.","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fdd565553d9def658e5e96b6fdfad48b84ee80d1","unresolved":false,"context_lines":[{"line_number":59,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":60,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":61,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":62,"context_line":"on a host from this object instead of making DB / API calls for each 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":10,"id":"3a961159_8a4cbc43","line":62,"updated":"2015-01-07 21:12:51.000000000","message":"Well, we could have some stale information about instances if we leave the periodic update_resource_stats() happening each 60secs.\n\nI would rather be in favor of finding another way to notify the Scheduler for each Instance change. That just means you need to provide a notify for each time a migration or a resize happens.","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"62c822f95fdf2179495818e7112feac9a83ba4f4","unresolved":false,"context_lines":[{"line_number":59,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":60,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":61,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":62,"context_line":"on a host from this object instead of making DB / API calls for each 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":10,"id":"3a961159_5bda764b","line":62,"in_reply_to":"3a961159_6d43113f","updated":"2015-01-09 11:32:02.000000000","message":"Well, the problem is that when claiming it only happens once the scheduler made a decision\n\nThat\u0027s racy : 2 instances can request the same host and the stats will only be updated when the first one is being spawned by the compute manager. In the mean time, scheduler has to decide for the 2nd one while it doesn\u0027t have a correct information...\n\nOn the current model, DB instances table is updated right before calling the scheduler so when the scheduler queries the DB, it already knows state for both instances","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"74589e36cfac7c2a07d5490f72b69bfc55e1aa9c","unresolved":false,"context_lines":[{"line_number":59,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":60,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":61,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":62,"context_line":"on a host from this object instead of making DB / API calls for each 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":10,"id":"3a961159_6d43113f","line":62,"in_reply_to":"3a961159_8a4cbc43","updated":"2015-01-08 16:18:09.000000000","message":"The compute manager notifies the ResourceTracker on every instance change, no? So I don\u0027t see how that would allow for stale information.","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"da58c3728150e47df748db69bf6199d678ea6569","unresolved":false,"context_lines":[{"line_number":59,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":60,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":61,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":62,"context_line":"on a host from this object instead of making DB / API calls for each 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":10,"id":"3a961159_3bd791c0","line":62,"in_reply_to":"3a961159_8a4cbc43","updated":"2015-01-08 06:36:50.000000000","message":"when resource claim at compute node, the ResourceTracker will update the resource usage, like https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L190\n\nBut now we only have resource cliam for resize, not for live_migration. live_migration can be fixed by https://bugs.launchpad.net/nova/+bug/1289064","commit_id":"d289c2491282bd17d89949e3a66a1bf77576d997"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"763a4f967968215227ac9f3c9caa7f46c3c19334","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Isolate Scheduler DB for Filters"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/isolate-scheduler-db"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_dbed86f1","line":8,"updated":"2015-01-09 11:33:34.000000000","message":"We need to isolate DB for all the filters, that\u0027s the role of the blueprint, but there are N specs per 1 BP and this one is focusing on how filters are accessing info related to instance\u0027 uuid and flavor","commit_id":"bda540dd603d6592879f7e9b14f6507e99f87469"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"763a4f967968215227ac9f3c9caa7f46c3c19334","unresolved":false,"context_lines":[{"line_number":39,"context_line":"Nova contributors wish to extend the functionality of the scheduler and intend"},{"line_number":40,"context_line":"to break the scheduler out into the Gantt project. In order to do this"},{"line_number":41,"context_line":"effectively, the internal interfaces around the scheduler and its filters must"},{"line_number":42,"context_line":"be updated to remove direct DB or API calls."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Project Priority"},{"line_number":45,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_1bbb8ee5","line":42,"updated":"2015-01-09 11:33:34.000000000","message":"Yeah, you can just write N/A\n\nThat whole section is overkill","commit_id":"bda540dd603d6592879f7e9b14f6507e99f87469"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"763a4f967968215227ac9f3c9caa7f46c3c19334","unresolved":false,"context_lines":[{"line_number":60,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":61,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":62,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":63,"context_line":"on a host from this object instead of making DB / API calls for each host."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Alternatives"},{"line_number":66,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3a961159_3bbe8ad4","line":63,"updated":"2015-01-09 11:33:34.000000000","message":"Reposting my previous comment on PS10 :\nWell, the problem is that when claiming it only happens once the scheduler made a decision\n\nThat\u0027s racy : 2 instances can request the same host and the stats will only be updated when the first one is being spawned by the compute manager. In the mean time, scheduler has to decide for the 2nd one while it doesn\u0027t have a correct information...\n\nOn the current model, DB instances table is updated right before calling the scheduler so when the scheduler queries the DB, it already knows state for both instances","commit_id":"bda540dd603d6592879f7e9b14f6507e99f87469"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"70cbcf6f667de819c6c60ad67646b28d2ba78d23","unresolved":false,"context_lines":[{"line_number":36,"context_line":"Use Cases"},{"line_number":37,"context_line":"----------"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"N/A"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Project Priority"},{"line_number":42,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_afbd6eb3","line":39,"updated":"2015-01-13 22:01:44.000000000","message":"Developers are \u0027users\u0027 too. So I think the use case should be:\n\nTo help enable the process of splitting on the nova-scheduler  etc.","commit_id":"2b86f8497cf88bb8503eb0bad843bfddc3ac7778"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"769a10a44f5b00e9f7e9aea151d9e47e04b05536","unresolved":false,"context_lines":[{"line_number":36,"context_line":"Use Cases"},{"line_number":37,"context_line":"----------"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"N/A"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Project Priority"},{"line_number":42,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_66646fe5","line":39,"in_reply_to":"3a961159_afbd6eb3","updated":"2015-01-14 17:07:51.000000000","message":"Heh, look at some of the previous patch sets. :)","commit_id":"2b86f8497cf88bb8503eb0bad843bfddc3ac7778"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a0bc84a5ec1c0143fa00dfa45727622f486c56b1","unresolved":false,"context_lines":[{"line_number":57,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":58,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":59,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":60,"context_line":"on a host from this object instead of making DB / API calls for each host."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_cee6664a","line":60,"updated":"2015-01-12 22:49:14.000000000","message":"Reposting my previous comment on PS10 : Well, the problem is that when claiming it only happens once the scheduler made a decision\n\nThat\u0027s racy : 2 instances can request the same host and the stats will only be updated when the first one is being spawned by the compute manager. In the mean time, scheduler has to decide for the 2nd one while it doesn\u0027t have a correct information...\n\nOn the current model, DB instances table is updated right before calling the scheduler so when the scheduler queries the DB, it already knows state for both instances","commit_id":"2b86f8497cf88bb8503eb0bad843bfddc3ac7778"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"9e42cedb44b8eaa3a555e83a399bab9aaccae01a","unresolved":false,"context_lines":[{"line_number":57,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":58,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":59,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":60,"context_line":"on a host from this object instead of making DB / API calls for each host."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"1a930d6b_effedd6a","line":60,"in_reply_to":"1a930d6b_af74d59c","updated":"2015-01-21 16:00:18.000000000","message":"Agreed. Race conditions can happen with the current design; this should neither solve that or make it worse.","commit_id":"2b86f8497cf88bb8503eb0bad843bfddc3ac7778"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"7b882d3818d1ae12ed016c19ff7f1f7c56074651","unresolved":false,"context_lines":[{"line_number":57,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":58,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":59,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":60,"context_line":"on a host from this object instead of making DB / API calls for each host."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_ca7de4b3","line":60,"in_reply_to":"3a961159_134239ab","updated":"2015-01-16 07:57:29.000000000","message":"Let me write what I get these days. Yesterday just losts in English. So let me write down.\n\nIf I understand correct, this problem already existed in current code. And pretty similar with that Ironic problem.\n\nThe problem is we make decision at Scheduler and need another validate decision at ResourceTracker.\n\nCurrently we have two places to avoid this kind of race, and they stop this race for a little different cases.\n\n1. Race between workers in same one scheduler instance\n\n    This is resolved by we consume the instance\u0027s usage after find out a host. The code at https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L162\n\n2. Race between multiple scheduler instances.\n\n    This is resolved by resource claiming in ResourceTracker at compute node side. When claiming resource, it will validate the decision that made by scheduler. If the validation is failed, it will trigger rescheduling. The code at https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2137\n\nSo related to this spec and affected by instance info\u0027s filter is TypeAffinityFilter. It can be fixed by the way that described as above.\n\nI\u0027m not sure this can be fixed by Resource object like Ironic bug. TypeAffinityFilter isn\u0027t check the resource consume. Maybe we can add _test_instance_on_host method in the Claim obj?\n\nThis is pretty ugly we have two places to use same way to consume and validate resource but with different code...\n\n\nAnd I found there is another strange thing. It is \u0027server group\u0027. Scheduler haven\u0027t stats info about server group. The server group info only setup before calling scheduler in conductor. So the server group race problem only can be detected by compute side. If we can track server group\u0027s stats in scheduler, at least we can stop the race if that happened between workers in same scheduler, not leave it to compute node side, that at least save one rescheduling. Is it worth we doing that now?","commit_id":"2b86f8497cf88bb8503eb0bad843bfddc3ac7778"},{"author":{"_account_id":7461,"name":"Paul Murray","email":"pmurray@hpe.com","username":"ptm"},"change_message_id":"772f9ce072c89e863db89619a776c19c1326ac04","unresolved":false,"context_lines":[{"line_number":57,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":58,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":59,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":60,"context_line":"on a host from this object instead of making DB / API calls for each host."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"1a930d6b_af74d59c","line":60,"in_reply_to":"3a961159_ca7de4b3","updated":"2015-01-21 15:48:32.000000000","message":"Do we need to solve the race problem as part of this spec? It would be reasonable to separate removal of db access from solving the race or making optimal use of the in-memory data.\n\nIf we keep a copy of the data reported by the update_resource_stats() for each compute node we can use that as the basis for each request - just as we do now going to the database, but without going to the database. That gets rid of the database access but doesn\u0027t change how things work.\n\nLater we can decide how to keep track of the placement decisions.\n\nI think this is a good idea because it changes one thing at a time. We can put more thought into how to deal with consistency across requests and across multiple schedulers. That step might even be left until we consider how to deal with claims if they are moved to the scheduler.","commit_id":"2b86f8497cf88bb8503eb0bad843bfddc3ac7778"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"a8b7ff5a67da729b93ad07fc69101dcaf93d2f69","unresolved":false,"context_lines":[{"line_number":57,"context_line":"also pass along the InstanceList object corresponding to the instances on the"},{"line_number":58,"context_line":"host. The Scheduler would maintain this InstanceList in memory for each host,"},{"line_number":59,"context_line":"and the filters would access the information that they need about the instances"},{"line_number":60,"context_line":"on a host from this object instead of making DB / API calls for each host."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"Alternatives"},{"line_number":63,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3a961159_134239ab","line":60,"in_reply_to":"3a961159_cee6664a","updated":"2015-01-13 15:22:32.000000000","message":"This problem could be trivially solved by having the HostStateManager keep track of pending instance to compute node assignments. Then, when determining if the compute node housed an instance in the same server group, the filter could check both the list of instances assigned to the compute node as well as any instance in the \"pending build\" list.","commit_id":"2b86f8497cf88bb8503eb0bad843bfddc3ac7778"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"d7e3e386e410c67120f8b30c4ca2a02b138c2a02","unresolved":false,"context_lines":[{"line_number":63,"context_line":"------------"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"An alternative design would be to add instance information to the hosts"},{"line_number":66,"context_line":"returned in the current _get_all_host_states() call. This would require adding"},{"line_number":67,"context_line":"a new field to the host object that would contain the InstanceList object"},{"line_number":68,"context_line":"corresponding to the current state of that host\u0027s instances. The field would be"},{"line_number":69,"context_line":"lazy-loaded to minimize unnecessary overhead. This approach is less desireable,"}],"source_content_type":"text/x-rst","patch_set":12,"id":"1a930d6b_151258b1","line":66,"updated":"2015-01-21 16:30:31.000000000","message":"So this bit is where i lost you guys - you want to augment update_resource_stats to include a list of instances per compute node, but that does nothing more than literally stick the \"resources\" dict straight into matching fields of the compute_node table.\n\nAnd the alternative is to \"add  a new field\" - I don\u0027t understand what is the difference here, or rather how would you implement the proposed change without actually doing the alternative.","commit_id":"2b86f8497cf88bb8503eb0bad843bfddc3ac7778"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"4cdd072047656f4b93e87bd1e1c0b5e2ee6e766e","unresolved":false,"context_lines":[{"line_number":55,"context_line":"information to the host_state objects that are already being passed to the"},{"line_number":56,"context_line":"filters. There would be a new attribute on the HostManager class to hold"},{"line_number":57,"context_line":"information about instances called ``_instance_info``, which would be a dict"},{"line_number":58,"context_line":"keyed on host name, with each value being the InstanceList for that host. This"},{"line_number":59,"context_line":"information would be populated initially when the Scheduler starts up, and"},{"line_number":60,"context_line":"would be maintained in-memory in the scheduler\u0027s host_manager object."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_011e6763","line":58,"updated":"2015-01-22 21:40:19.000000000","message":"Mmm, don\u0027t you think we should rather have a list of instances in the HostManager and just point the reference of the instance to the HostState rather ? It would sound better if you want to update an instance","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"0b776788fe2dff30f370950dd09ba2ffbbf160fc","unresolved":false,"context_lines":[{"line_number":55,"context_line":"information to the host_state objects that are already being passed to the"},{"line_number":56,"context_line":"filters. There would be a new attribute on the HostManager class to hold"},{"line_number":57,"context_line":"information about instances called ``_instance_info``, which would be a dict"},{"line_number":58,"context_line":"keyed on host name, with each value being the InstanceList for that host. This"},{"line_number":59,"context_line":"information would be populated initially when the Scheduler starts up, and"},{"line_number":60,"context_line":"would be maintained in-memory in the scheduler\u0027s host_manager object."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_61c00be1","line":58,"in_reply_to":"1a930d6b_011e6763","updated":"2015-01-22 22:17:44.000000000","message":"But the way that the HostManager will use this information is to add it to the HostState object. Keying on the host makes this straightforward.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"ed33e7859c1a9e8b8771cd5e8ccb7cd9fde64d10","unresolved":false,"context_lines":[{"line_number":55,"context_line":"information to the host_state objects that are already being passed to the"},{"line_number":56,"context_line":"filters. There would be a new attribute on the HostManager class to hold"},{"line_number":57,"context_line":"information about instances called ``_instance_info``, which would be a dict"},{"line_number":58,"context_line":"keyed on host name, with each value being the InstanceList for that host. This"},{"line_number":59,"context_line":"information would be populated initially when the Scheduler starts up, and"},{"line_number":60,"context_line":"would be maintained in-memory in the scheduler\u0027s host_manager object."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_5f64ade4","line":58,"in_reply_to":"1a930d6b_355f0774","updated":"2015-01-23 14:02:45.000000000","message":"For the initial startup, yes, as I was trying to mirror the process that would be done while the scheduler is running. But I can make it a single call at startup; see my comments below.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"cea8eecf334e7b7bdaeea99348cf1a45547380b3","unresolved":false,"context_lines":[{"line_number":55,"context_line":"information to the host_state objects that are already being passed to the"},{"line_number":56,"context_line":"filters. There would be a new attribute on the HostManager class to hold"},{"line_number":57,"context_line":"information about instances called ``_instance_info``, which would be a dict"},{"line_number":58,"context_line":"keyed on host name, with each value being the InstanceList for that host. This"},{"line_number":59,"context_line":"information would be populated initially when the Scheduler starts up, and"},{"line_number":60,"context_line":"would be maintained in-memory in the scheduler\u0027s host_manager object."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_355f0774","line":58,"in_reply_to":"1a930d6b_61c00be1","updated":"2015-01-23 12:42:25.000000000","message":"I don\u0027t think a list of Instances would not be better... See my comments below, it means that you\u0027re uploading per host","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9a52dfe02c7efd6ec9eaf408cb0b49ee17c9341f","unresolved":false,"context_lines":[{"line_number":63,"context_line":"instances (create/ destroy/ resize), or when a new compute node comes online,"},{"line_number":64,"context_line":"the compute node would notify the scheduler with its current InstanceList. This"},{"line_number":65,"context_line":"would be done via a new RPC API method for the scheduler called"},{"line_number":66,"context_line":"``update_host_instance_info()``. The method would accept a dict of (host_name:"},{"line_number":67,"context_line":"InstanceList) pairs, and would pass that information to the scheduler client"},{"line_number":68,"context_line":"via an RPC fanout cast so that the update is sent to all schedulers. On the"},{"line_number":69,"context_line":"scheduler side of the call, this information would be used to update the"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_49133b66","line":66,"updated":"2015-01-22 19:41:17.000000000","message":"This seems quite heavyweight to me, as opposed to just notifying the scheduler that an instance has been created/deleted/resized. But, I\u0027m OK with the first version of the API being a single method like this, I guess.\n\nCan we name it update_compute_node_instance_info(), though, to be consistently referring to the target object as a compute node and not a host?","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"45f92480041c686d429343421efe89898aea4165","unresolved":false,"context_lines":[{"line_number":63,"context_line":"instances (create/ destroy/ resize), or when a new compute node comes online,"},{"line_number":64,"context_line":"the compute node would notify the scheduler with its current InstanceList. This"},{"line_number":65,"context_line":"would be done via a new RPC API method for the scheduler called"},{"line_number":66,"context_line":"``update_host_instance_info()``. The method would accept a dict of (host_name:"},{"line_number":67,"context_line":"InstanceList) pairs, and would pass that information to the scheduler client"},{"line_number":68,"context_line":"via an RPC fanout cast so that the update is sent to all schedulers. On the"},{"line_number":69,"context_line":"scheduler side of the call, this information would be used to update the"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_0a4be187","line":66,"in_reply_to":"1a930d6b_49133b66","updated":"2015-01-22 20:59:14.000000000","message":"I think that the main idea is for the Scheduler to have a complete view of the instances. Eventually it will be via a scheduler-owned db, but for now, the InstanceList is an object representation of the instances in the nova db.\n\nI used \u0027host\u0027 instead of \u0027compute_node\u0027 for consistency, since we have \u0027get_all_host_states\u0027, and are passing a \u0027host_state\u0027 object to the filters. Also, the method of InstanceList is named \u0027get_by_host()\u0027. I prefer compute_node, too, but it doesn\u0027t seem that we could use the consistency argument here.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"4cdd072047656f4b93e87bd1e1c0b5e2ee6e766e","unresolved":false,"context_lines":[{"line_number":64,"context_line":"the compute node would notify the scheduler with its current InstanceList. This"},{"line_number":65,"context_line":"would be done via a new RPC API method for the scheduler called"},{"line_number":66,"context_line":"``update_host_instance_info()``. The method would accept a dict of (host_name:"},{"line_number":67,"context_line":"InstanceList) pairs, and would pass that information to the scheduler client"},{"line_number":68,"context_line":"via an RPC fanout cast so that the update is sent to all schedulers. On the"},{"line_number":69,"context_line":"scheduler side of the call, this information would be used to update the"},{"line_number":70,"context_line":"host_manager\u0027s _instance_info attribute. The HostManager class\u0027s"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_810a571f","line":67,"updated":"2015-01-22 21:40:19.000000000","message":"I don\u0027t understand why you need to update all the instances from a compute node when only one instance would be updated.\n\nI was thinking more about an update_instance(inst, node) which would update the list of instances (which doesn\u0027t need to be an InstanceList object, but that\u0027s a nitpick) which would do the necessary update (ie. find the current host for the instance and either update it or move it from the src host to the dst host)","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"0b776788fe2dff30f370950dd09ba2ffbbf160fc","unresolved":false,"context_lines":[{"line_number":64,"context_line":"the compute node would notify the scheduler with its current InstanceList. This"},{"line_number":65,"context_line":"would be done via a new RPC API method for the scheduler called"},{"line_number":66,"context_line":"``update_host_instance_info()``. The method would accept a dict of (host_name:"},{"line_number":67,"context_line":"InstanceList) pairs, and would pass that information to the scheduler client"},{"line_number":68,"context_line":"via an RPC fanout cast so that the update is sent to all schedulers. On the"},{"line_number":69,"context_line":"scheduler side of the call, this information would be used to update the"},{"line_number":70,"context_line":"host_manager\u0027s _instance_info attribute. The HostManager class\u0027s"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_813c17e4","line":67,"in_reply_to":"1a930d6b_810a571f","updated":"2015-01-22 22:17:44.000000000","message":"I want to mirror the eventual situation where this information is persisted in a scheduler-owned db. It also greatly simplifies keeping everything current, as each update is a snapshot of a host\u0027s instances at that moment. There is no need for the scheduler to know anything about the actions of a host, such as migration, resizing, creation, deletion, etc. All it needs to know is \"here are my instances right now\". This mirrors what a DB query would return without having to add DB persistence to the scheduler.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9a52dfe02c7efd6ec9eaf408cb0b49ee17c9341f","unresolved":false,"context_lines":[{"line_number":71,"context_line":"``get_all_host_states()`` method would be augmented to add the InstanceList for"},{"line_number":72,"context_line":"each host to the host_state object. These host_state objects are passed to the"},{"line_number":73,"context_line":"filters, and the filters would then access information about instances directly"},{"line_number":74,"context_line":"from the host_state object instead of making DB/API calls."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"The initial population of the instance information would be done via a new call"},{"line_number":77,"context_line":"to the HostManager: ``get_all_host_instances()``. This would call"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_e4b96e16","line":74,"updated":"2015-01-22 19:41:17.000000000","message":"OK, this is fine for this spec.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"0b776788fe2dff30f370950dd09ba2ffbbf160fc","unresolved":false,"context_lines":[{"line_number":71,"context_line":"``get_all_host_states()`` method would be augmented to add the InstanceList for"},{"line_number":72,"context_line":"each host to the host_state object. These host_state objects are passed to the"},{"line_number":73,"context_line":"filters, and the filters would then access information about instances directly"},{"line_number":74,"context_line":"from the host_state object instead of making DB/API calls."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"The initial population of the instance information would be done via a new call"},{"line_number":77,"context_line":"to the HostManager: ``get_all_host_instances()``. This would call"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_c10c5f45","line":74,"in_reply_to":"1a930d6b_6151eb0d","updated":"2015-01-22 22:17:44.000000000","message":"That\u0027s not correct. Since the HostManager doesn\u0027t persist HostState objects between calls, but instead creates them fresh with each request, there won\u0027t be any HostState objects hanging around to update. The HostManager will persist this information in-memory using the proposed \u0027_instance_info\u0027 attribute.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"ed33e7859c1a9e8b8771cd5e8ccb7cd9fde64d10","unresolved":false,"context_lines":[{"line_number":71,"context_line":"``get_all_host_states()`` method would be augmented to add the InstanceList for"},{"line_number":72,"context_line":"each host to the host_state object. These host_state objects are passed to the"},{"line_number":73,"context_line":"filters, and the filters would then access information about instances directly"},{"line_number":74,"context_line":"from the host_state object instead of making DB/API calls."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"The initial population of the instance information would be done via a new call"},{"line_number":77,"context_line":"to the HostManager: ``get_all_host_instances()``. This would call"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_9fe37532","line":74,"in_reply_to":"1a930d6b_75850fac","updated":"2015-01-23 14:02:45.000000000","message":"I think that this would be very inefficient, as it would have to be calculated with each request. I think when a request comes in, the HostManager should simply add the InstanceList for each host to the HostState without having to re-calculate anything.\n\nWhen starting up, I think your idea of calling InstanceList.get_all() is workable. But once it retrieves that list of instances, it then does a calculation similar to the one you want to run with every scheduling request in order to create the dict of {host: InstanceList} that it would then persist in memory.\n\nKeep in mind that the Scheduler is only concerned about the state of the compute nodes; instances mean nothing except in the context of their host. And when the scheduler is a separate entity with its own DB, it will also need to have a host-centric view of the system; instances are simply one aspect of a compute node, and not interesting by themselves. The approach I\u0027m proposing is closer to the design we will need for an independent scheduler, and will make the eventual separation much easier.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"cea8eecf334e7b7bdaeea99348cf1a45547380b3","unresolved":false,"context_lines":[{"line_number":71,"context_line":"``get_all_host_states()`` method would be augmented to add the InstanceList for"},{"line_number":72,"context_line":"each host to the host_state object. These host_state objects are passed to the"},{"line_number":73,"context_line":"filters, and the filters would then access information about instances directly"},{"line_number":74,"context_line":"from the host_state object instead of making DB/API calls."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"The initial population of the instance information would be done via a new call"},{"line_number":77,"context_line":"to the HostManager: ``get_all_host_instances()``. This would call"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_75850fac","line":74,"in_reply_to":"1a930d6b_c10c5f45","updated":"2015-01-23 12:42:25.000000000","message":"I think you misunderstood me.\nLet me explain further :\n\n  HostManager._instances \u003d InstanceList.get_all()\n\nThen you have a list of objects in _instances\n\nSo, when running get_all_host_states(), you can create     \n\n HostState.instances \u003d [ instance for HostManager._instances if instance.host \u003d\u003d HostState.host ]\n\nIt would keep the references in HostManager while the objects would be called in HostState","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"4cdd072047656f4b93e87bd1e1c0b5e2ee6e766e","unresolved":false,"context_lines":[{"line_number":71,"context_line":"``get_all_host_states()`` method would be augmented to add the InstanceList for"},{"line_number":72,"context_line":"each host to the host_state object. These host_state objects are passed to the"},{"line_number":73,"context_line":"filters, and the filters would then access information about instances directly"},{"line_number":74,"context_line":"from the host_state object instead of making DB/API calls."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"The initial population of the instance information would be done via a new call"},{"line_number":77,"context_line":"to the HostManager: ``get_all_host_instances()``. This would call"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_6151eb0d","line":74,"in_reply_to":"1a930d6b_e4b96e16","updated":"2015-01-22 21:40:19.000000000","message":"I think we need to clarify that we would just update the references from the HostManager to the relative HostState.instances field","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"4cdd072047656f4b93e87bd1e1c0b5e2ee6e766e","unresolved":false,"context_lines":[{"line_number":78,"context_line":"db.compute_node_get_all() to get a list of all the compute nodes, and then call"},{"line_number":79,"context_line":"InstanceList.get_by_host() for each compute node. The result would be a dict of"},{"line_number":80,"context_line":"host_name: InstanceList key/value pairs that would represent the state of the"},{"line_number":81,"context_line":"instances on all compute node when the scheduler starts up."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":84,"context_line":"be added to the ComputeManager class called ``_update_instance_info()``. This"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_4175cf96","line":81,"updated":"2015-01-22 21:40:19.000000000","message":"Here that\u0027s why I think it would be better to refer to the instances directly in the HostManager instead of calling twice the DB when starting nova-scheduler...","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"0b776788fe2dff30f370950dd09ba2ffbbf160fc","unresolved":false,"context_lines":[{"line_number":78,"context_line":"db.compute_node_get_all() to get a list of all the compute nodes, and then call"},{"line_number":79,"context_line":"InstanceList.get_by_host() for each compute node. The result would be a dict of"},{"line_number":80,"context_line":"host_name: InstanceList key/value pairs that would represent the state of the"},{"line_number":81,"context_line":"instances on all compute node when the scheduler starts up."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":84,"context_line":"be added to the ComputeManager class called ``_update_instance_info()``. This"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_b4af8fe2","line":81,"in_reply_to":"1a930d6b_4175cf96","updated":"2015-01-22 22:17:44.000000000","message":"It\u0027s possible to simply get all instances at init, and then construct the _instance_info dict. I chose this approach because it mirrored the update process: basically, it was getting an InstanceList per host. If we were to get all Instances in the scheduler init, the scheduler would have to manually create InstanceList objects from them. I think this would be much less efficient than using the exiting get_by_host() method.\n\nAlso, this is only happening when the scheduler starts up. I don\u0027t believe that this will create any sort of performance issue.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"4cdd072047656f4b93e87bd1e1c0b5e2ee6e766e","unresolved":false,"context_lines":[{"line_number":81,"context_line":"instances on all compute node when the scheduler starts up."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":84,"context_line":"be added to the ComputeManager class called ``_update_instance_info()``. This"},{"line_number":85,"context_line":"would generate the appropriate InstanceList object for that host, and call the"},{"line_number":86,"context_line":"scheduler RPC API with the {host_name: InstanceList} dict. The scheduler\u0027s"},{"line_number":87,"context_line":"host_manager would update its _instance_info attribute with the new"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_215e0313","line":84,"updated":"2015-01-22 21:40:19.000000000","message":"this section seems a bit different from the one you said 2 sections above (the method name is different and also the signature)","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"ed33e7859c1a9e8b8771cd5e8ccb7cd9fde64d10","unresolved":false,"context_lines":[{"line_number":81,"context_line":"instances on all compute node when the scheduler starts up."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":84,"context_line":"be added to the ComputeManager class called ``_update_instance_info()``. This"},{"line_number":85,"context_line":"would generate the appropriate InstanceList object for that host, and call the"},{"line_number":86,"context_line":"scheduler RPC API with the {host_name: InstanceList} dict. The scheduler\u0027s"},{"line_number":87,"context_line":"host_manager would update its _instance_info attribute with the new"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_3ffa81bd","line":84,"in_reply_to":"1a930d6b_14e30334","updated":"2015-01-23 14:02:45.000000000","message":"OK, I just realized that I confused two different things in my reply above. There will be a private method in compute that will be called when instances change, and it will be called \u0027_update_scheduler_instance_info()\u0027. That method will call the RPC API method, which will look like: \n\n  scheduler_client.update_instance_info(...)","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"0b776788fe2dff30f370950dd09ba2ffbbf160fc","unresolved":false,"context_lines":[{"line_number":81,"context_line":"instances on all compute node when the scheduler starts up."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":84,"context_line":"be added to the ComputeManager class called ``_update_instance_info()``. This"},{"line_number":85,"context_line":"would generate the appropriate InstanceList object for that host, and call the"},{"line_number":86,"context_line":"scheduler RPC API with the {host_name: InstanceList} dict. The scheduler\u0027s"},{"line_number":87,"context_line":"host_manager would update its _instance_info attribute with the new"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_14e30334","line":84,"in_reply_to":"1a930d6b_215e0313","updated":"2015-01-22 22:17:44.000000000","message":"Since this is running on the compute node, adding \u0027host\u0027 to the name doesn\u0027t make sense. But I do think that changing this to \u0027_update_scheduler_instance_info()\u0027 would be clearer, so I\u0027ll make that change.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9a52dfe02c7efd6ec9eaf408cb0b49ee17c9341f","unresolved":false,"context_lines":[{"line_number":94,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":97,"context_line":"the action has succeeded before updating the scheduler."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":14,"id":"1a930d6b_c45552c7","line":97,"updated":"2015-01-22 19:41:17.000000000","message":"OK, good for now.","commit_id":"6ca7da7f019c335db8fdbc2771ba41f0fe928ce5"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5714099dd998f9bd7a86af93183d3e0f023a8aa0","unresolved":false,"context_lines":[{"line_number":176,"context_line":"  - Add the RPC API call to the SchedulerAPI class for the ComputeManager to"},{"line_number":177,"context_line":"    call when instances change"},{"line_number":178,"context_line":"  - Add a method to the HostManager that will accept the (host_name:"},{"line_number":179,"context_line":"    InstanceList) key/value pairs and store/update a new ``_instance_info``"},{"line_number":180,"context_line":"    attribute accordingly"},{"line_number":181,"context_line":"  - Update the HostManager\u0027s _get_all_host_states() to add the InstanceList"},{"line_number":182,"context_line":"    information to each host"}],"source_content_type":"text/x-rst","patch_set":15,"id":"1a930d6b_d54b2385","line":179,"updated":"2015-01-23 12:44:04.000000000","message":"as said in PS14, I don\u0027t think we need to provide an InstanceList attribute","commit_id":"f7586d670127feb7f705cada98022a3db3aa9aec"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"c2cc46104399f565463ad2576022d1527a07d26d","unresolved":false,"context_lines":[{"line_number":176,"context_line":"  - Add the RPC API call to the SchedulerAPI class for the ComputeManager to"},{"line_number":177,"context_line":"    call when instances change"},{"line_number":178,"context_line":"  - Add a method to the HostManager that will accept the (host_name:"},{"line_number":179,"context_line":"    InstanceList) key/value pairs and store/update a new ``_instance_info``"},{"line_number":180,"context_line":"    attribute accordingly"},{"line_number":181,"context_line":"  - Update the HostManager\u0027s _get_all_host_states() to add the InstanceList"},{"line_number":182,"context_line":"    information to each host"}],"source_content_type":"text/x-rst","patch_set":15,"id":"1a930d6b_c2836654","line":179,"in_reply_to":"1a930d6b_d54b2385","updated":"2015-01-23 14:27:28.000000000","message":"OK, let me try explaining again. There are two ways for the scheduler to always have an accurate picture of the state of the instances on the hosts it will be responsible for scheduling. Both start with some initial process to get the state when the scheduler starts up. What happens as the scheduler is running is where we differ.\n\nOne approach, which you seem to favor, is to have the compute nodes send the scheduler only the information about an instance that has changed. That information will be received by the scheduler, which will then have to have the intelligence to handle all the different state changes. E.g., the logic to process a new instance being created would be very different than the logic to process an instance being destroyed. We would have to add to the scheduler a lot of knowledge about the internals of compute (resizing, migrating, etc.). That logic would then have to be maintained in both compute and scheduler.\n\nThe other approach keeps all the logic in compute; when a change happens, compute simply passes the scheduler the result: i.e., a \u0027snapshot\u0027 of the state of its current instances. This would not require the scheduler to understand anything about how compute works; all it really cares about is that compute node A has InstanceList A right now. It can then use that current information to make the filtering decisions required.","commit_id":"f7586d670127feb7f705cada98022a3db3aa9aec"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5714099dd998f9bd7a86af93183d3e0f023a8aa0","unresolved":false,"context_lines":[{"line_number":182,"context_line":"    information to each host"},{"line_number":183,"context_line":"  - Remove the current db/api calls in the filters, and modify the code to look"},{"line_number":184,"context_line":"    for the InstanceList information in in the host_state object instead."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Dependencies"},{"line_number":188,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":15,"id":"1a930d6b_b554d721","line":185,"updated":"2015-01-23 12:44:04.000000000","message":"I don\u0027t see where/when you plan to call the new RPC API methods that you\u0027re creating","commit_id":"f7586d670127feb7f705cada98022a3db3aa9aec"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"c2cc46104399f565463ad2576022d1527a07d26d","unresolved":false,"context_lines":[{"line_number":182,"context_line":"    information to each host"},{"line_number":183,"context_line":"  - Remove the current db/api calls in the filters, and modify the code to look"},{"line_number":184,"context_line":"    for the InstanceList information in in the host_state object instead."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Dependencies"},{"line_number":188,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":15,"id":"1a930d6b_027e4e6b","line":185,"in_reply_to":"1a930d6b_b554d721","updated":"2015-01-23 14:27:28.000000000","message":"Good catch. Done.","commit_id":"f7586d670127feb7f705cada98022a3db3aa9aec"},{"author":{"_account_id":1849,"name":"Joe Gordon","email":"joe.gordon0@gmail.com","username":"jogo"},"change_message_id":"67f58df552f8b88da93e5ce0ff7fff55ad167726","unresolved":false,"context_lines":[{"line_number":24,"context_line":""},{"line_number":25,"context_line":"* TypeAffinityFilter"},{"line_number":26,"context_line":"* SameHostFilter"},{"line_number":27,"context_line":"* DifferentHostFilter"},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"The first needs to know all the flavors on a host, and the others need to know"},{"line_number":30,"context_line":"the UUIDs of all instances on the host.  Their current method of api/db access"}],"source_content_type":"text/x-rst","patch_set":17,"id":"fa81d914_51096394","line":27,"updated":"2015-01-27 22:25:53.000000000","message":"If someone isn\u0027t running any of these schedulers, we should be able to turn off passing around this extra data.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"f441bab8ee89b72e3be65a5d2c59cd1f52d48cb1","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"The first needs to know all the flavors on a host, and the others need to know"},{"line_number":30,"context_line":"the UUIDs of all instances on the host.  Their current method of api/db access"},{"line_number":31,"context_line":"prevents the scheduler from being separated as an indpendent service. These"},{"line_number":32,"context_line":"filters need to be updated to use host state objects in the scheduler instead"},{"line_number":33,"context_line":"of accessing the db directly or calling the nova compute API."},{"line_number":34,"context_line":""}],"source_content_type":"text/x-rst","patch_set":17,"id":"fa81d914_11528bdd","line":31,"updated":"2015-01-27 21:44:49.000000000","message":"s/indpendent/independent/","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"f441bab8ee89b72e3be65a5d2c59cd1f52d48cb1","unresolved":false,"context_lines":[{"line_number":55,"context_line":"information to the host_state objects that are already being passed to the"},{"line_number":56,"context_line":"filters. There would be a new attribute on the HostManager class to hold"},{"line_number":57,"context_line":"information about instances called ``_instance_info``, which would be a dict"},{"line_number":58,"context_line":"keyed on host name, with each value being the InstanceList for that host. This"},{"line_number":59,"context_line":"information would be populated initially when the Scheduler starts up, and"},{"line_number":60,"context_line":"would be maintained in-memory in the scheduler\u0027s host_manager object."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":17,"id":"fa81d914_315eafea","line":58,"updated":"2015-01-27 21:44:49.000000000","message":"We talked about this at the mid-cycle. The people in the room were concerned this data structure will be quite large, and we wondered by this information couldn\u0027t be reported by the resource tracker as well.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"be97df7e9470dbbd7fae588bcf2c5f7f514a04d9","unresolved":false,"context_lines":[{"line_number":55,"context_line":"information to the host_state objects that are already being passed to the"},{"line_number":56,"context_line":"filters. There would be a new attribute on the HostManager class to hold"},{"line_number":57,"context_line":"information about instances called ``_instance_info``, which would be a dict"},{"line_number":58,"context_line":"keyed on host name, with each value being the InstanceList for that host. This"},{"line_number":59,"context_line":"information would be populated initially when the Scheduler starts up, and"},{"line_number":60,"context_line":"would be maintained in-memory in the scheduler\u0027s host_manager object."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_686b1fb7","line":58,"updated":"2015-01-27 10:51:57.000000000","message":"question on: is it ok we depend on nova object when we want to split scheduler.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"9b443b482b4a677f313c8bbdf1a36e846ed95d52","unresolved":false,"context_lines":[{"line_number":55,"context_line":"information to the host_state objects that are already being passed to the"},{"line_number":56,"context_line":"filters. There would be a new attribute on the HostManager class to hold"},{"line_number":57,"context_line":"information about instances called ``_instance_info``, which would be a dict"},{"line_number":58,"context_line":"keyed on host name, with each value being the InstanceList for that host. This"},{"line_number":59,"context_line":"information would be populated initially when the Scheduler starts up, and"},{"line_number":60,"context_line":"would be maintained in-memory in the scheduler\u0027s host_manager object."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_8077289f","line":58,"in_reply_to":"1a930d6b_686b1fb7","updated":"2015-01-27 15:20:27.000000000","message":"When the scheduler is split, the objects will be created from the DB owned by the scheduler, not nova. By using nova objects now, we minimize the code changes necessary when we switch where this information is stored.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"f12929b9a30d5d9a9e01a71d29e965611f991e15","unresolved":false,"context_lines":[{"line_number":55,"context_line":"information to the host_state objects that are already being passed to the"},{"line_number":56,"context_line":"filters. There would be a new attribute on the HostManager class to hold"},{"line_number":57,"context_line":"information about instances called ``_instance_info``, which would be a dict"},{"line_number":58,"context_line":"keyed on host name, with each value being the InstanceList for that host. This"},{"line_number":59,"context_line":"information would be populated initially when the Scheduler starts up, and"},{"line_number":60,"context_line":"would be maintained in-memory in the scheduler\u0027s host_manager object."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":17,"id":"fa81d914_a55c1527","line":58,"in_reply_to":"fa81d914_315eafea","updated":"2015-01-27 23:41:53.000000000","message":"This really wouldn\u0027t reduce the size of the information. We would have to change this to simply track instance UUIDs and instance_type_ids per host, which would greatly reduce flexibility for new filters, and would require another major code redesign when we move to a scheduler-owned DB.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"45ea1586f6467259e7768a0752413140f85015ac","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":" * init_host()          - when a new host comes online"},{"line_number":93,"context_line":" * _build_instance()    - when a new instance is created"},{"line_number":94,"context_line":" * _complete_deletion() - when an instance is destroyed"},{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_a22735b5","line":94,"updated":"2015-01-23 16:08:36.000000000","message":"Pass a empty dict for that instance means delete, right? I remember I heard that from you before.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"9b443b482b4a677f313c8bbdf1a36e846ed95d52","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":" * init_host()          - when a new host comes online"},{"line_number":93,"context_line":" * _build_instance()    - when a new instance is created"},{"line_number":94,"context_line":" * _complete_deletion() - when an instance is destroyed"},{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_40bd4001","line":94,"in_reply_to":"1a930d6b_2db6898a","updated":"2015-01-27 15:20:27.000000000","message":"Right now it would be a premature optimization. If it turns out that this is prohibitively slow, we can create a blueprint to write the code that will handle all the diffs, and keeping the copy of instances in the scheduler in sync with what is actually deployed. With the complete InstanceList, we are assured that what the scheduler sees is what is in the nova DB.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"378ccc7b51dc92f1bbacfb9c0d4a29e9a5cedb10","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":" * init_host()          - when a new host comes online"},{"line_number":93,"context_line":" * _build_instance()    - when a new instance is created"},{"line_number":94,"context_line":" * _complete_deletion() - when an instance is destroyed"},{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_db58a834","line":94,"in_reply_to":"1a930d6b_a22735b5","updated":"2015-01-23 16:37:26.000000000","message":"That was an early approach, which has been rejected. Now at the end of each of these, the compute node will pass a single dict: {host: InstanceList}. In the case of deletion, the deleted instance will not be in the InstanceList.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"be97df7e9470dbbd7fae588bcf2c5f7f514a04d9","unresolved":false,"context_lines":[{"line_number":91,"context_line":""},{"line_number":92,"context_line":" * init_host()          - when a new host comes online"},{"line_number":93,"context_line":" * _build_instance()    - when a new instance is created"},{"line_number":94,"context_line":" * _complete_deletion() - when an instance is destroyed"},{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_2db6898a","line":94,"in_reply_to":"1a930d6b_db58a834","updated":"2015-01-27 10:51:57.000000000","message":"ok, I see now. Is it required update all the instance? Just update the changed is more effective?","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"be97df7e9470dbbd7fae588bcf2c5f7f514a04d9","unresolved":false,"context_lines":[{"line_number":92,"context_line":" * init_host()          - when a new host comes online"},{"line_number":93,"context_line":" * _build_instance()    - when a new instance is created"},{"line_number":94,"context_line":" * _complete_deletion() - when an instance is destroyed"},{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":98,"context_line":"the action has succeeded before updating the scheduler."}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_ad2ef9a2","line":95,"updated":"2015-01-27 10:51:57.000000000","message":"also for live_migration, unshelve, and evacuate/rebuild? This should be for any action make the instance rescheduling I guess","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"9b443b482b4a677f313c8bbdf1a36e846ed95d52","unresolved":false,"context_lines":[{"line_number":92,"context_line":" * init_host()          - when a new host comes online"},{"line_number":93,"context_line":" * _build_instance()    - when a new instance is created"},{"line_number":94,"context_line":" * _complete_deletion() - when an instance is destroyed"},{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":98,"context_line":"the action has succeeded before updating the scheduler."}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_e0a70c09","line":95,"in_reply_to":"1a930d6b_ad2ef9a2","updated":"2015-01-27 15:20:27.000000000","message":"Yes. If there are other methods where the number and size of instances change, they will need to call the update.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"45ea1586f6467259e7768a0752413140f85015ac","unresolved":false,"context_lines":[{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":98,"context_line":"the action has succeeded before updating the scheduler."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_0211e9ab","line":98,"updated":"2015-01-23 16:08:36.000000000","message":"This is not updated at same time with instance_claim. Update stats at the end of these method make thing more simpler. I\u0027m just thinking is there any problem for the short window of stats inconsistent between instance_claim and the end of methods...looks like nothing wrong.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":7461,"name":"Paul Murray","email":"pmurray@hpe.com","username":"ptm"},"change_message_id":"69b47db5e0452ede6efb1422c13599ba4a1a65b6","unresolved":false,"context_lines":[{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":98,"context_line":"the action has succeeded before updating the scheduler."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_36c0e37b","line":98,"in_reply_to":"1a930d6b_0211e9ab","updated":"2015-01-23 17:05:48.000000000","message":"As this works with multiple calls (update_resource_stats() and this new update_instance_info()) instead of a single DB update we do not have atomicity. So there will always be a little inconsistency like that.\n\nThe host gets set in the instance claim, but I don\u0027t think there is a reason why the notification to the scheduler needs to be there. The checks that are done on the host already are the important ones, if the scheduler selects an invalid host due to inconsistent update the host will sort it out with a reschedule.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"378ccc7b51dc92f1bbacfb9c0d4a29e9a5cedb10","unresolved":false,"context_lines":[{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":98,"context_line":"the action has succeeded before updating the scheduler."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_bb867c63","line":98,"in_reply_to":"1a930d6b_0211e9ab","updated":"2015-01-23 16:37:26.000000000","message":"Yes, there will be a similar possibility of a race condition here, but since it is only the instances we are concerned with, and not the overall resources (which *are* claimed correctly), the only place where a race could occur is in the three filters, not in any of the HostState resources.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"d661ac3d542d4cfb5ba870ca9debe9d93507af23","unresolved":false,"context_lines":[{"line_number":95,"context_line":" * _finish_resize()     - when an instance is resized"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":98,"context_line":"the action has succeeded before updating the scheduler."},{"line_number":99,"context_line":""},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_51bf39fb","line":98,"in_reply_to":"1a930d6b_36c0e37b","updated":"2015-01-23 17:28:33.000000000","message":"Paul, remember that this has nothing to do with resources on the host. Instead, it\u0027s simply a replacement for the calls that the 3 filters specified use to get information about instances on a host. There is the same chance for a race condition with RAM, disk, etc., as there is now.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":7461,"name":"Paul Murray","email":"pmurray@hpe.com","username":"ptm"},"change_message_id":"69b47db5e0452ede6efb1422c13599ba4a1a65b6","unresolved":false,"context_lines":[{"line_number":102,"context_line":"------------"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"An alternative, and overall much cleaner, design would be to add the"},{"line_number":105,"context_line":"InstanceList as a lazy-loaded attribute of the ComputeNode object.  When the"},{"line_number":106,"context_line":"scheduler starts up, instead of only retrieving a dict of (host_name:"},{"line_number":107,"context_line":"InstanceList) values, a ComputeNodeList would be retrieved and stored in-memory"},{"line_number":108,"context_line":"by the HostManager. There would be no more reason to call"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_d6279f62","line":105,"updated":"2015-01-23 17:05:48.000000000","message":"This would probably lead to a rapid succession of calls to the database as each host being examined is loaded. It is more efficient to just get the info for all hosts in a single call.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"d661ac3d542d4cfb5ba870ca9debe9d93507af23","unresolved":false,"context_lines":[{"line_number":102,"context_line":"------------"},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"An alternative, and overall much cleaner, design would be to add the"},{"line_number":105,"context_line":"InstanceList as a lazy-loaded attribute of the ComputeNode object.  When the"},{"line_number":106,"context_line":"scheduler starts up, instead of only retrieving a dict of (host_name:"},{"line_number":107,"context_line":"InstanceList) values, a ComputeNodeList would be retrieved and stored in-memory"},{"line_number":108,"context_line":"by the HostManager. There would be no more reason to call"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_b1093ddf","line":105,"in_reply_to":"1a930d6b_d6279f62","updated":"2015-01-23 17:28:33.000000000","message":"An earlier discussion suggested that lazy-loading would be more efficient for all those times that ComputeNode is used without caring about its instances. In this case, where we want them, maybe there could be a parameter to load them up front.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":7461,"name":"Paul Murray","email":"pmurray@hpe.com","username":"ptm"},"change_message_id":"69b47db5e0452ede6efb1422c13599ba4a1a65b6","unresolved":false,"context_lines":[{"line_number":144,"context_line":""},{"line_number":145,"context_line":"There will be some improvement as a result of each of the three filters not"},{"line_number":146,"context_line":"having to make a DB or API call for each host, but this will be minimal and is"},{"line_number":147,"context_line":"not the driving force behind making these changes."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"Other deployer impact"},{"line_number":150,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":17,"id":"1a930d6b_76ed0bef","line":147,"updated":"2015-01-23 17:05:48.000000000","message":"Actually this can be very significant, but agree its not the point.","commit_id":"b940292941de0d1717c843b9190a1473d279f50f"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9c5cc1c91d299e0eb96c6173bfe416941a61d619","unresolved":false,"context_lines":[{"line_number":64,"context_line":"information about instances called ``_instance_info``, which would be a dict"},{"line_number":65,"context_line":"keyed on host name, with each value being the InstanceList for that host. This"},{"line_number":66,"context_line":"information would be populated initially when the Scheduler starts up, and"},{"line_number":67,"context_line":"would be maintained in-memory in the scheduler\u0027s host_manager object."},{"line_number":68,"context_line":""},{"line_number":69,"context_line":"Additionally, whenever a significant change happens to any of a compute node\u0027s"},{"line_number":70,"context_line":"instances (create/ destroy/ resize), or when a new compute node comes online,"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_6d40f1a5","line":67,"updated":"2015-02-03 11:02:11.000000000","message":"some details can be tackled later in the implementation, so +1 it","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9c5cc1c91d299e0eb96c6173bfe416941a61d619","unresolved":false,"context_lines":[{"line_number":84,"context_line":"to the HostManager: ``get_all_host_instances()``. This would call"},{"line_number":85,"context_line":"objects.Instance.get_all() to get all the instances, and then construct the"},{"line_number":86,"context_line":"{host: InstanceList} dict that would populate the \u0027_instance_info\u0027 attribute."},{"line_number":87,"context_line":"The result would be a dict of {host_name: InstanceList} key/value pairs that"},{"line_number":88,"context_line":"would represent the state of the instances on all compute node when the"},{"line_number":89,"context_line":"scheduler starts up."},{"line_number":90,"context_line":""}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_cd1c7dc4","line":87,"updated":"2015-02-03 11:02:11.000000000","message":"that\u0027s duplicate of what you said L65, but that\u0027s fine","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9c5cc1c91d299e0eb96c6173bfe416941a61d619","unresolved":false,"context_lines":[{"line_number":94,"context_line":"add a new CONF setting that will default to True. If a deployer knows that"},{"line_number":95,"context_line":"their setup doesn\u0027t use any of these filters, they can change that to False."},{"line_number":96,"context_line":"Compute nodes will read this setting at startup, and if it is False, they will"},{"line_number":97,"context_line":"not update the scheduler when their instances change."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":100,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_2da19947","line":97,"updated":"2015-02-03 11:02:11.000000000","message":"There are 3 filters using the Instances API. Should we only leave one CONF opt ?\n\nAlso, I would be in favor of defining that opt in scheduler.utils module for making sure that we keep track those","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a932c0265d71de1e8598f1735b0c739a31ebd411","unresolved":false,"context_lines":[{"line_number":94,"context_line":"add a new CONF setting that will default to True. If a deployer knows that"},{"line_number":95,"context_line":"their setup doesn\u0027t use any of these filters, they can change that to False."},{"line_number":96,"context_line":"Compute nodes will read this setting at startup, and if it is False, they will"},{"line_number":97,"context_line":"not update the scheduler when their instances change."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"While passing entire Instance objects might be considered a \u0027heavy\u0027 approach,"},{"line_number":100,"context_line":"it would be preferred over just passing the instance_type_id and UUID, for two"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_1b7241e5","line":97,"in_reply_to":"da86d52c_2da19947","updated":"2015-02-03 16:51:20.000000000","message":"It\u0027s either a) report instance info, or b) don\u0027t report instance info. So only one CONF opt is needed.\n\nThe CONF opt affects compute, so I don\u0027t think that it should be in scheduler.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9c5cc1c91d299e0eb96c6173bfe416941a61d619","unresolved":false,"context_lines":[{"line_number":113,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":114,"context_line":"be added to the ComputeManager class called"},{"line_number":115,"context_line":"``_update_scheduler_instance_info()``. This would generate the appropriate"},{"line_number":116,"context_line":"InstanceList object for that host, and call the scheduler RPC API with the"},{"line_number":117,"context_line":"{host_name: InstanceList} dict. The scheduler\u0027s host_manager would update its"},{"line_number":118,"context_line":"_instance_info attribute with the new InstanceList value. The ComputeManager"},{"line_number":119,"context_line":"would have to have this call to _update_instance_info() in several places:"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_0d4f7593","line":116,"updated":"2015-02-03 11:02:11.000000000","message":"it should rather call the scheduler client, which itself would call the Scheduler RPC API","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a932c0265d71de1e8598f1735b0c739a31ebd411","unresolved":false,"context_lines":[{"line_number":113,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":114,"context_line":"be added to the ComputeManager class called"},{"line_number":115,"context_line":"``_update_scheduler_instance_info()``. This would generate the appropriate"},{"line_number":116,"context_line":"InstanceList object for that host, and call the scheduler RPC API with the"},{"line_number":117,"context_line":"{host_name: InstanceList} dict. The scheduler\u0027s host_manager would update its"},{"line_number":118,"context_line":"_instance_info attribute with the new InstanceList value. The ComputeManager"},{"line_number":119,"context_line":"would have to have this call to _update_instance_info() in several places:"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_e193fc4c","line":116,"in_reply_to":"da86d52c_0d4f7593","updated":"2015-02-03 16:51:20.000000000","message":"Yeah, I messed up that distinction between versions. Fixed.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"e8acbb731f681f64a0577ce930296692cc3120e0","unresolved":false,"context_lines":[{"line_number":116,"context_line":"InstanceList object for that host, and call the scheduler RPC API with the"},{"line_number":117,"context_line":"{host_name: InstanceList} dict. The scheduler\u0027s host_manager would update its"},{"line_number":118,"context_line":"_instance_info attribute with the new InstanceList value. The ComputeManager"},{"line_number":119,"context_line":"would have to have this call to _update_instance_info() in several places:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":" * init_host()                  - when a new host comes online"},{"line_number":122,"context_line":" * _build_instance()            - when a new instance is created"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_14ba5ede","line":119,"updated":"2015-02-02 08:39:49.000000000","message":"It isn\u0027t all the instance\u0027s properties only changed by any kind of rescheduling. Like the instance\u0027s status, we can pause, unpause, that won\u0027t trigger the rescheduling, and the status in scheduler will be old. Also like instance\u0027s network(add new nic or remove nic) changed, it won\u0027t be triggered also. Should we think about those think? or we think those old info is ok? At least ok for now, nobody use those instance\u0027s properties yet.\n\nIf we don\u0027t think those old info is ok, we still need update instance info in \u0027update_available_resource\u0027 for each 60 secs.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"97c8c8f86244c4a54cdb5b4f85fd7f18a6d6e2d1","unresolved":false,"context_lines":[{"line_number":116,"context_line":"InstanceList object for that host, and call the scheduler RPC API with the"},{"line_number":117,"context_line":"{host_name: InstanceList} dict. The scheduler\u0027s host_manager would update its"},{"line_number":118,"context_line":"_instance_info attribute with the new InstanceList value. The ComputeManager"},{"line_number":119,"context_line":"would have to have this call to _update_instance_info() in several places:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":" * init_host()                  - when a new host comes online"},{"line_number":122,"context_line":" * _build_instance()            - when a new instance is created"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_33592eff","line":119,"in_reply_to":"da86d52c_14ba5ede","updated":"2015-02-02 13:47:07.000000000","message":"Right now the only qualities of the instance that we are concerned about is its UUID and its instance_type_id, neither of which change in your cases. This is just a transitional state to stop the scheduler from making DB or nova API calls for its current filters. Resources for compute nodes are still updated in the current manner.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"03ef84fd3ff2106850f8348810d51e703542afbb","unresolved":false,"context_lines":[{"line_number":116,"context_line":"InstanceList object for that host, and call the scheduler RPC API with the"},{"line_number":117,"context_line":"{host_name: InstanceList} dict. The scheduler\u0027s host_manager would update its"},{"line_number":118,"context_line":"_instance_info attribute with the new InstanceList value. The ComputeManager"},{"line_number":119,"context_line":"would have to have this call to _update_instance_info() in several places:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":" * init_host()                  - when a new host comes online"},{"line_number":122,"context_line":" * _build_instance()            - when a new instance is created"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_367d9c6f","line":119,"in_reply_to":"da86d52c_33592eff","updated":"2015-02-02 14:04:12.000000000","message":"ok, i see now, that make sense for me.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"03ef84fd3ff2106850f8348810d51e703542afbb","unresolved":false,"context_lines":[{"line_number":119,"context_line":"would have to have this call to _update_instance_info() in several places:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":" * init_host()                  - when a new host comes online"},{"line_number":122,"context_line":" * _build_instance()            - when a new instance is created"},{"line_number":123,"context_line":" * _complete_deletion()         - when an instance is destroyed"},{"line_number":124,"context_line":" * _finish_resize()             - when an instance is resized"},{"line_number":125,"context_line":" * shelve_offload_instance()    - when a shelved instance is destroyed"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_33b76e88","line":122,"updated":"2015-02-02 14:04:12.000000000","message":"nit, I guess you mean \u0027_build_and_run_instance\u0027. \u0027_build_instance\u0027 is old method, that we didn\u0027t use anymore.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"85f5fbb11e8f1b8815f689838f8d964bf2ff9d59","unresolved":false,"context_lines":[{"line_number":119,"context_line":"would have to have this call to _update_instance_info() in several places:"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":" * init_host()                  - when a new host comes online"},{"line_number":122,"context_line":" * _build_instance()            - when a new instance is created"},{"line_number":123,"context_line":" * _complete_deletion()         - when an instance is destroyed"},{"line_number":124,"context_line":" * _finish_resize()             - when an instance is resized"},{"line_number":125,"context_line":" * shelve_offload_instance()    - when a shelved instance is destroyed"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_c1746b9e","line":122,"in_reply_to":"da86d52c_33b76e88","updated":"2015-02-02 17:26:47.000000000","message":"Yes, you are correct. I was looking at the scheduler method.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"e8acbb731f681f64a0577ce930296692cc3120e0","unresolved":false,"context_lines":[{"line_number":124,"context_line":" * _finish_resize()             - when an instance is resized"},{"line_number":125,"context_line":" * shelve_offload_instance()    - when a shelved instance is destroyed"},{"line_number":126,"context_line":" * _complete_partial_deletion() - when an instance marked deleted is destroyed"},{"line_number":127,"context_line":" * _reschedule_or_error()       - when a failed instance is deleted"},{"line_number":128,"context_line":" * _build_resources()           - when cleaning up failed builds"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"All of the calls would come at the end of these methods, when we are sure that"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_94bbae0d","line":127,"updated":"2015-02-02 08:39:49.000000000","message":"You will call update instance at the end of these method(as line 131 said), I guess there isn\u0027t  any chance to reschedule again.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"85f5fbb11e8f1b8815f689838f8d964bf2ff9d59","unresolved":false,"context_lines":[{"line_number":124,"context_line":" * _finish_resize()             - when an instance is resized"},{"line_number":125,"context_line":" * shelve_offload_instance()    - when a shelved instance is destroyed"},{"line_number":126,"context_line":" * _complete_partial_deletion() - when an instance marked deleted is destroyed"},{"line_number":127,"context_line":" * _reschedule_or_error()       - when a failed instance is deleted"},{"line_number":128,"context_line":" * _build_resources()           - when cleaning up failed builds"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"All of the calls would come at the end of these methods, when we are sure that"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_81f193cf","line":127,"in_reply_to":"da86d52c_565db020","updated":"2015-02-02 17:26:47.000000000","message":"Ah, ok, I understand what you\u0027re asking. If there has been a failure to spawn the instance, the reschedule would have been triggered, and L2241 wouldn\u0027t have been reached in the code. The call to \u0027_update_scheduler_instance_info()\u0027 would only happen after the completion of the method; i.e., when the instance had been created. Until then, there are no instance changes to update scheduler with. On a reschedule, if that succeeds, then that rescheduled instance will trigger the update.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"03ef84fd3ff2106850f8348810d51e703542afbb","unresolved":false,"context_lines":[{"line_number":124,"context_line":" * _finish_resize()             - when an instance is resized"},{"line_number":125,"context_line":" * shelve_offload_instance()    - when a shelved instance is destroyed"},{"line_number":126,"context_line":" * _complete_partial_deletion() - when an instance marked deleted is destroyed"},{"line_number":127,"context_line":" * _reschedule_or_error()       - when a failed instance is deleted"},{"line_number":128,"context_line":" * _build_resources()           - when cleaning up failed builds"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"All of the calls would come at the end of these methods, when we are sure that"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_565db020","line":127,"in_reply_to":"da86d52c_931d7a12","updated":"2015-02-02 14:04:12.000000000","message":"sorry for my english. I mean you said you will call \u0027_update_scheduler_instance_info\u0027 at the end of those methods. For building instance, I guess you will call at https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2241\n\nAt that line, there isn\u0027t any chance to trigger a rescheduling.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"97c8c8f86244c4a54cdb5b4f85fd7f18a6d6e2d1","unresolved":false,"context_lines":[{"line_number":124,"context_line":" * _finish_resize()             - when an instance is resized"},{"line_number":125,"context_line":" * shelve_offload_instance()    - when a shelved instance is destroyed"},{"line_number":126,"context_line":" * _complete_partial_deletion() - when an instance marked deleted is destroyed"},{"line_number":127,"context_line":" * _reschedule_or_error()       - when a failed instance is deleted"},{"line_number":128,"context_line":" * _build_resources()           - when cleaning up failed builds"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"All of the calls would come at the end of these methods, when we are sure that"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_931d7a12","line":127,"in_reply_to":"da86d52c_94bbae0d","updated":"2015-02-02 13:47:07.000000000","message":"I don\u0027t follow - the failed instance has already been added to the scheduler\u0027s view of things, and if it fails, it should be removed from that view when it is deleted. Rescheduling should not be affected at all, unless I\u0027m missing something.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9c5cc1c91d299e0eb96c6173bfe416941a61d619","unresolved":false,"context_lines":[{"line_number":134,"context_line":"scheduler is updated, we also need to handle the situation where we do not have"},{"line_number":135,"context_line":"current information about the instances on a compute node, since pre-Kilo nodes"},{"line_number":136,"context_line":"will not be doing the updates described in the above paragraph. To handle this,"},{"line_number":137,"context_line":"a new integer column will be added to the ComputeNode table to indicate"},{"line_number":138,"context_line":"versioning. It will be initialized to 0. ComputeNodes running Kilo will update"},{"line_number":139,"context_line":"that column to 1 upon startup. This way when the scheduler gets the ComputeNode"},{"line_number":140,"context_line":"object, it will know whether or not it is running a version that is sending"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_50e2e603","line":137,"updated":"2015-02-03 11:02:11.000000000","message":"s/ComputeNode/compute_nodes table","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a932c0265d71de1e8598f1735b0c739a31ebd411","unresolved":false,"context_lines":[{"line_number":134,"context_line":"scheduler is updated, we also need to handle the situation where we do not have"},{"line_number":135,"context_line":"current information about the instances on a compute node, since pre-Kilo nodes"},{"line_number":136,"context_line":"will not be doing the updates described in the above paragraph. To handle this,"},{"line_number":137,"context_line":"a new integer column will be added to the ComputeNode table to indicate"},{"line_number":138,"context_line":"versioning. It will be initialized to 0. ComputeNodes running Kilo will update"},{"line_number":139,"context_line":"that column to 1 upon startup. This way when the scheduler gets the ComputeNode"},{"line_number":140,"context_line":"object, it will know whether or not it is running a version that is sending"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_7eaecb86","line":137,"in_reply_to":"da86d52c_50e2e603","updated":"2015-02-03 16:51:20.000000000","message":"Done","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9c5cc1c91d299e0eb96c6173bfe416941a61d619","unresolved":false,"context_lines":[{"line_number":135,"context_line":"current information about the instances on a compute node, since pre-Kilo nodes"},{"line_number":136,"context_line":"will not be doing the updates described in the above paragraph. To handle this,"},{"line_number":137,"context_line":"a new integer column will be added to the ComputeNode table to indicate"},{"line_number":138,"context_line":"versioning. It will be initialized to 0. ComputeNodes running Kilo will update"},{"line_number":139,"context_line":"that column to 1 upon startup. This way when the scheduler gets the ComputeNode"},{"line_number":140,"context_line":"object, it will know whether or not it is running a version that is sending"},{"line_number":141,"context_line":"updates, and if not, would revert to the current behavior of direct DB/API"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_50b026f4","line":138,"updated":"2015-02-03 11:02:11.000000000","message":"You don\u0027t need to initialize it, you just need to default it to 0","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a932c0265d71de1e8598f1735b0c739a31ebd411","unresolved":false,"context_lines":[{"line_number":135,"context_line":"current information about the instances on a compute node, since pre-Kilo nodes"},{"line_number":136,"context_line":"will not be doing the updates described in the above paragraph. To handle this,"},{"line_number":137,"context_line":"a new integer column will be added to the ComputeNode table to indicate"},{"line_number":138,"context_line":"versioning. It will be initialized to 0. ComputeNodes running Kilo will update"},{"line_number":139,"context_line":"that column to 1 upon startup. This way when the scheduler gets the ComputeNode"},{"line_number":140,"context_line":"object, it will know whether or not it is running a version that is sending"},{"line_number":141,"context_line":"updates, and if not, would revert to the current behavior of direct DB/API"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_fed2bbd0","line":138,"in_reply_to":"da86d52c_50b026f4","updated":"2015-02-03 16:51:20.000000000","message":"Done","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"9c5cc1c91d299e0eb96c6173bfe416941a61d619","unresolved":false,"context_lines":[{"line_number":164,"context_line":"-----------------"},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"None. There is no extra information to persist, as the scheduler will maintain"},{"line_number":167,"context_line":"this information in memory."},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"REST API impact"},{"line_number":170,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_d0ffb6a8","line":167,"updated":"2015-02-03 11:02:11.000000000","message":"you need to update that section re: what you said L133 and follows","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a932c0265d71de1e8598f1735b0c739a31ebd411","unresolved":false,"context_lines":[{"line_number":164,"context_line":"-----------------"},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"None. There is no extra information to persist, as the scheduler will maintain"},{"line_number":167,"context_line":"this information in memory."},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"REST API impact"},{"line_number":170,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":18,"id":"da86d52c_def2576e","line":167,"in_reply_to":"da86d52c_d0ffb6a8","updated":"2015-02-03 16:51:20.000000000","message":"Done","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"a8ceaa7b5f3f463f76eac158320b5046a183a0f5","unresolved":false,"context_lines":[{"line_number":229,"context_line":"    they call the \u0027_update_scheduler_instance_info()\u0027 method, unless the CONF"},{"line_number":230,"context_line":"    flag for this behavior has been turned off: init_host(), _build_instance(),"},{"line_number":231,"context_line":"    _complete_deletion(), _finish_resize(), shelve_offload_instance(),"},{"line_number":232,"context_line":"    _complete_partial_deletion(), _reschedule_or_error(), _build_resources()."},{"line_number":233,"context_line":"  - Create the ``_update_scheduler_instance_info()`` method in the"},{"line_number":234,"context_line":"    ComputeManager class to generate the current InstanceList for that node,"},{"line_number":235,"context_line":"    and pass it to the scheduler via RPC."}],"source_content_type":"text/x-rst","patch_set":18,"id":"fa81d914_1cd7c2c0","line":232,"updated":"2015-01-29 00:24:37.000000000","message":"I do wonder if this should be somehow related to the resource tracker calls, so people don\u0027t forget to add this when they add new methods. But I am thinking out loud.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"2e27be269ec9afd64fd6854fd4a008654f6d77d7","unresolved":false,"context_lines":[{"line_number":229,"context_line":"    they call the \u0027_update_scheduler_instance_info()\u0027 method, unless the CONF"},{"line_number":230,"context_line":"    flag for this behavior has been turned off: init_host(), _build_instance(),"},{"line_number":231,"context_line":"    _complete_deletion(), _finish_resize(), shelve_offload_instance(),"},{"line_number":232,"context_line":"    _complete_partial_deletion(), _reschedule_or_error(), _build_resources()."},{"line_number":233,"context_line":"  - Create the ``_update_scheduler_instance_info()`` method in the"},{"line_number":234,"context_line":"    ComputeManager class to generate the current InstanceList for that node,"},{"line_number":235,"context_line":"    and pass it to the scheduler via RPC."}],"source_content_type":"text/x-rst","patch_set":18,"id":"fa81d914_83e890e3","line":232,"in_reply_to":"fa81d914_1cd7c2c0","updated":"2015-01-29 14:15:28.000000000","message":"That was one of the earlier ideas, but since the RT is updated at other times, such as _allocate_network_async(), it was a bit of overkill.\n\nI\u0027m thinking that if there were a simple enough way for the compute node to diff its state when something might have changed, it would avoid sending useless updates, and the overall size of the updates could be reduced significantly.","commit_id":"c2211e782b318b406b1ad94ed51b4a3c77f0c090"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6bd18e2a0832b1f91e96e7d10979f425dad11c8d","unresolved":false,"context_lines":[{"line_number":108,"context_line":"  - The design for how this information is used will be much closer to what it"},{"line_number":109,"context_line":"    will be when we separate the scheduler into its own service with its own"},{"line_number":110,"context_line":"    database. Stripping this down to just the data that is needed now will mean"},{"line_number":111,"context_line":"    more work later on."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":114,"context_line":"be added to the ComputeManager class called"}],"source_content_type":"text/x-rst","patch_set":20,"id":"da86d52c_3893f550","line":111,"updated":"2015-02-06 19:14:18.000000000","message":"So, I think that passing all the instance objects on each call is indeed too heavyweight. It would really suck to generate a bunch of rabbit load, passing 25 instances that are still running just so that the scheduler can notice that one was deleted.\n\nI think I\u0027d propose breaking this into two pieces:\n\nThe first would be a call that we make during an action (list below) that tells the scheduler that Instance $foo was {added,deleted,changed} and then pass the instance. We\u0027ve already got that instance object in scope for those operations, so this should be easy and avoids the need to produce an instance list (from whichever source). That will be a much lighter call to be done as frequently as it will happen. There might need to be a list provided for init_host() but otherwise I think all the other operations are affecting a single instance.\n\nThe second would be a periodic sync of the list of uuids (only) that are running on the host. This provides the scheduler the double check ability to make sure that none of the above notifications were dropped. If it finds one that is running on a compute node unexpectedly, the scheduler infrastructure can query (once) to patch up its cache, which is still more efficient than each filter doing it separately.","commit_id":"55a414584c2b8f6eaf2fa442181e460682c4e026"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"676f9426ce771f6e20824de84a02e67ff00fcfb1","unresolved":false,"context_lines":[{"line_number":108,"context_line":"  - The design for how this information is used will be much closer to what it"},{"line_number":109,"context_line":"    will be when we separate the scheduler into its own service with its own"},{"line_number":110,"context_line":"    database. Stripping this down to just the data that is needed now will mean"},{"line_number":111,"context_line":"    more work later on."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":114,"context_line":"be added to the ComputeManager class called"}],"source_content_type":"text/x-rst","patch_set":20,"id":"da86d52c_232586ae","line":111,"in_reply_to":"da86d52c_3893f550","updated":"2015-02-06 19:34:54.000000000","message":"The pendulum swings back again... :)\n\nWhat you\u0027re describing is very similar to version 6 of this spec: https://review.openstack.org/#/c/138444/6/specs/kilo/approved/isolate-scheduler-db-filters.rst,cm\n\nIf we\u0027re going to go lightweight, I would think that simply adding the instance info to the get_all_host_states() hosts would be cleaner, and wouldn\u0027t require the syncing step. The scheduler wouldn\u0027t need to keep anything in memory, so there would be nothing to get stale.","commit_id":"55a414584c2b8f6eaf2fa442181e460682c4e026"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"c7a7ac6129f092a573e2043342e849d895e49c1a","unresolved":false,"context_lines":[{"line_number":144,"context_line":"current behavior of direct DB/API calls to get that information for each host"},{"line_number":145,"context_line":"in the HostManager\u0027s ``get_all_host_states()`` method. As the nodes get updated"},{"line_number":146,"context_line":"and restarted, they will update their version in the DB, and the HostManager"},{"line_number":147,"context_line":"will be able to use the instance information it has in memory."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":20,"id":"da86d52c_d260fad1","line":147,"updated":"2015-02-06 18:05:50.000000000","message":"While I don\u0027t hate the approach that is proposed above I feel that it is not general  enough and will tie us down to supporting an interface for communicating between Scheduler and Compute nodes that does not really solve a general problem.\n\nAfter speaking to several users who extend scheduling with their own data that computes expose - the general pattern seems to be:\n\n* Compute nodes expose the addotonal data (store it in the DB or likely a 3rd data-store)\n* Scheduler queries the data when doing filtering for each compute node that is being considered by the filter that needs the data and makes the decision.\n\nNote that I do not want to specify if it is querying and exposing via the DB, RPC call or something else (obviously the basic implementations is via the DB for instances)\n\nI feel that the problem we want to be solving is figuring the API for 1) compute to expose data 2) Filters to query this data. get_all_host_instances() is likely a rat hole that we don\u0027t want to go down, it is just not general enough.\n\nThis is of course closely tied to actually figuring out the interface of the future Gantt.\n\nAt the point we have this kind of thing - caching becomes a tunable implementation detial of the scheduler. We may want to cache stuff if we want to provide quick decision making for the users requesting placement based on the additional data, or we may want to make the scheduler more \"consistent\" at the cost of lower performance.","commit_id":"55a414584c2b8f6eaf2fa442181e460682c4e026"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6bd18e2a0832b1f91e96e7d10979f425dad11c8d","unresolved":false,"context_lines":[{"line_number":144,"context_line":"current behavior of direct DB/API calls to get that information for each host"},{"line_number":145,"context_line":"in the HostManager\u0027s ``get_all_host_states()`` method. As the nodes get updated"},{"line_number":146,"context_line":"and restarted, they will update their version in the DB, and the HostManager"},{"line_number":147,"context_line":"will be able to use the instance information it has in memory."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":20,"id":"da86d52c_5d817bfa","line":147,"in_reply_to":"da86d52c_d260fad1","updated":"2015-02-06 19:14:18.000000000","message":"I don\u0027t think the aim is to solve the general problem. The approach is to communicate some of the information we currently query from the DB to the scheduler so that it doesn\u0027t talk to the DB directly. It\u0027s not adding a new resource type, it\u0027s just changing the way we communicate existing information to the scheduler in a way that supports isolating the scheduler from the DB without dropping functionality (i.e. disabling those filters).\n\nUnless we\u0027re going to hinge the rest of the scheduler stuff on designing a new method for communicating all resources, I\u0027m not sure what the alternative is. Are you proposing something different?\n\nIMHO, we\u0027re just talking about exposing the instances that are running on the host. That list is something that has been a fundamental property of what a compute node does since the beginning of time, and will continue until Nova fully morphs into a full-service espresso bar. As such, I\u0027m really not concerned about it being a \"rat hole that ... is not general enough.\"","commit_id":"55a414584c2b8f6eaf2fa442181e460682c4e026"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"f549c9c7ce87a0cee25202f17ee07af235a335c7","unresolved":false,"context_lines":[{"line_number":144,"context_line":"current behavior of direct DB/API calls to get that information for each host"},{"line_number":145,"context_line":"in the HostManager\u0027s ``get_all_host_states()`` method. As the nodes get updated"},{"line_number":146,"context_line":"and restarted, they will update their version in the DB, and the HostManager"},{"line_number":147,"context_line":"will be able to use the instance information it has in memory."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":20,"id":"da86d52c_f87cfdb7","line":147,"in_reply_to":"da86d52c_d260fad1","updated":"2015-02-06 19:26:13.000000000","message":"Nikola: this is an interim solution. The long-term goal of a separate Gantt scheduler would have the scheduler owning this data. Since it is currently in the nova DB, this is a way to remove the need for the scheduler to ask each host for its instances on each and every iteration of the 3 filters in question.","commit_id":"55a414584c2b8f6eaf2fa442181e460682c4e026"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"a7ad335c55d315fd98f2e02ab6930b8135762ee0","unresolved":false,"context_lines":[{"line_number":144,"context_line":"current behavior of direct DB/API calls to get that information for each host"},{"line_number":145,"context_line":"in the HostManager\u0027s ``get_all_host_states()`` method. As the nodes get updated"},{"line_number":146,"context_line":"and restarted, they will update their version in the DB, and the HostManager"},{"line_number":147,"context_line":"will be able to use the instance information it has in memory."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":20,"id":"da86d52c_1d3623b5","line":147,"in_reply_to":"da86d52c_d260fad1","updated":"2015-02-06 18:41:07.000000000","message":"What alternative are you proposing, if any, Nikola?","commit_id":"55a414584c2b8f6eaf2fa442181e460682c4e026"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"baecdfe89a5480a516f4534c9d9e4c349feb2fe3","unresolved":false,"context_lines":[{"line_number":56,"context_line":""},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Proposed change"},{"line_number":59,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"Rather than have the filters make DB or API calls, we will add the instance"},{"line_number":62,"context_line":"information to the host_state objects that are already being passed to the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_143475fa","line":59,"updated":"2015-02-12 11:22:56.000000000","message":"It might be helpful to split this section up into multiple subsections, EG outline; API impact; desync recovery; online upgrade; performance (oh wait we have a section for that)","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"7ba7c059e6ab41a4ff1c864860c90717d807b1bd","unresolved":false,"context_lines":[{"line_number":56,"context_line":""},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"Proposed change"},{"line_number":59,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"Rather than have the filters make DB or API calls, we will add the instance"},{"line_number":62,"context_line":"information to the host_state objects that are already being passed to the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_ce287c88","line":59,"in_reply_to":"da86d52c_143475fa","updated":"2015-02-12 15:31:32.000000000","message":"OK, I think that will be clearer.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"baecdfe89a5480a516f4534c9d9e4c349feb2fe3","unresolved":false,"context_lines":[{"line_number":69,"context_line":"Additionally, whenever a significant change happens to any of a compute node\u0027s"},{"line_number":70,"context_line":"instances (create/ destroy/ resize), or when a new compute node comes online,"},{"line_number":71,"context_line":"the compute node would notify the scheduler by sending the Instance object, or,"},{"line_number":72,"context_line":"in the case of a terminated instance, just the uuid of the terminated instance."},{"line_number":73,"context_line":"This would be done via a new RPC API method for the scheduler called"},{"line_number":74,"context_line":"``update_instance_info()``. The method would require 3 parameters:"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_23d94157","line":72,"updated":"2015-02-12 11:22:56.000000000","message":"nit: this sentence has six commas and two separate alternations (\u0027or\u0027s). Maybe it could be split up?","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"7ba7c059e6ab41a4ff1c864860c90717d807b1bd","unresolved":false,"context_lines":[{"line_number":69,"context_line":"Additionally, whenever a significant change happens to any of a compute node\u0027s"},{"line_number":70,"context_line":"instances (create/ destroy/ resize), or when a new compute node comes online,"},{"line_number":71,"context_line":"the compute node would notify the scheduler by sending the Instance object, or,"},{"line_number":72,"context_line":"in the case of a terminated instance, just the uuid of the terminated instance."},{"line_number":73,"context_line":"This would be done via a new RPC API method for the scheduler called"},{"line_number":74,"context_line":"``update_instance_info()``. The method would require 3 parameters:"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_ae2d0891","line":72,"in_reply_to":"da86d52c_23d94157","updated":"2015-02-12 15:31:32.000000000","message":"The grammar nazi in me agrees with you. :)","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1fcdfa484bcef5123354c72610cefd5369e31ec9","unresolved":false,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"  * host_name: the host sending the information"},{"line_number":77,"context_line":"  * instance_info: either an Instance object, a UUID, or a list of UUIDs"},{"line_number":78,"context_line":"  * action: one of \u0027create\u0027, \u0027update\u0027, \u0027delete\u0027, or \u0027sync\u0027"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The compute node would call the scheduler client, which would then send the"},{"line_number":81,"context_line":"information to all running schedulers via an RPC fanout cast. On the scheduler"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_fe4529b4","line":78,"updated":"2015-02-11 15:19:20.000000000","message":"are we sure we need an action arg ? I would rather be in favor of 2 distinct methods more RESTful-ish :\n - update_instance_info(host, instance)\n - delete_instance_info(host, instance_uuid)\n\nThat way, our interfaces are stabilized and the argument types are also clearly identified : instance is an Instance object for the former method, and instance_uuid is just an uuid.uuid4() type\n\nYour point about passing a list of instances for avoiding to call multiple times the RPC API is valid. I would then be in favor of :\n\n - update_instances_info(host, instances) (instances being an InstanceList object which can have only one item)\n - delete_instances_info(host, instance_uuids) (where instance_uuids is a list of uuids - or a set, I don\u0027t really care)","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"7ba7c059e6ab41a4ff1c864860c90717d807b1bd","unresolved":false,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"  * host_name: the host sending the information"},{"line_number":77,"context_line":"  * instance_info: either an Instance object, a UUID, or a list of UUIDs"},{"line_number":78,"context_line":"  * action: one of \u0027create\u0027, \u0027update\u0027, \u0027delete\u0027, or \u0027sync\u0027"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The compute node would call the scheduler client, which would then send the"},{"line_number":81,"context_line":"information to all running schedulers via an RPC fanout cast. On the scheduler"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_eeee2021","line":78,"in_reply_to":"da86d52c_0d638c42","updated":"2015-02-12 15:31:32.000000000","message":"OK, it\u0027s not that critical to me. I\u0027ll change it to separate RPC calls for update, delete, and sync. Update will include both create and update events.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"085336843aed7da3a65e87a5d3d682c2b2a8da38","unresolved":false,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"  * host_name: the host sending the information"},{"line_number":77,"context_line":"  * instance_info: either an Instance object, a UUID, or a list of UUIDs"},{"line_number":78,"context_line":"  * action: one of \u0027create\u0027, \u0027update\u0027, \u0027delete\u0027, or \u0027sync\u0027"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The compute node would call the scheduler client, which would then send the"},{"line_number":81,"context_line":"information to all running schedulers via an RPC fanout cast. On the scheduler"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_a8028a3b","line":78,"in_reply_to":"da86d52c_740eb58d","updated":"2015-02-11 18:15:02.000000000","message":"I\u0027m really sorry, but I don\u0027t get your point about sync","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"baecdfe89a5480a516f4534c9d9e4c349feb2fe3","unresolved":false,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"  * host_name: the host sending the information"},{"line_number":77,"context_line":"  * instance_info: either an Instance object, a UUID, or a list of UUIDs"},{"line_number":78,"context_line":"  * action: one of \u0027create\u0027, \u0027update\u0027, \u0027delete\u0027, or \u0027sync\u0027"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The compute node would call the scheduler client, which would then send the"},{"line_number":81,"context_line":"information to all running schedulers via an RPC fanout cast. On the scheduler"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_0d638c42","line":78,"in_reply_to":"da86d52c_a8028a3b","updated":"2015-02-12 11:22:56.000000000","message":"I agree this would be better as 3 calls rather than have the type of \u0027instance_info\u0027 depend on \u0027action\u0027.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"128b9e3c37eeebb6f77baf45f7fe07eef3284e87","unresolved":false,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"  * host_name: the host sending the information"},{"line_number":77,"context_line":"  * instance_info: either an Instance object, a UUID, or a list of UUIDs"},{"line_number":78,"context_line":"  * action: one of \u0027create\u0027, \u0027update\u0027, \u0027delete\u0027, or \u0027sync\u0027"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"The compute node would call the scheduler client, which would then send the"},{"line_number":81,"context_line":"information to all running schedulers via an RPC fanout cast. On the scheduler"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_740eb58d","line":78,"in_reply_to":"da86d52c_fe4529b4","updated":"2015-02-11 16:49:41.000000000","message":"We would definitely need 3 methods, then: update (which would include create), delete, and sync.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1fcdfa484bcef5123354c72610cefd5369e31ec9","unresolved":false,"context_lines":[{"line_number":91,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client"},{"line_number":92,"context_line":"with the action specified as \u0027sync\u0027. This could be added to the"},{"line_number":93,"context_line":"ComputeManager\u0027s update_available_resource() method, since this also runs"},{"line_number":94,"context_line":"periodically."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The update would require that the HostManager locate the entry for the"},{"line_number":97,"context_line":"specified host in its _instance_info dict, and then use the \u0027action\u0027 parameter"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_ded865f1","line":94,"updated":"2015-02-11 15:19:20.000000000","message":"as I said above, I don\u0027t think we need a sync action, we just need to consider that what comes thru the RPC API is always proritary to what\u0027s already in the scheduler HostManager","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"b7a88ebf9c44e0c04d61a4e0fbba5851265d5567","unresolved":false,"context_lines":[{"line_number":91,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client"},{"line_number":92,"context_line":"with the action specified as \u0027sync\u0027. This could be added to the"},{"line_number":93,"context_line":"ComputeManager\u0027s update_available_resource() method, since this also runs"},{"line_number":94,"context_line":"periodically."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The update would require that the HostManager locate the entry for the"},{"line_number":97,"context_line":"specified host in its _instance_info dict, and then use the \u0027action\u0027 parameter"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_83004802","line":94,"in_reply_to":"da86d52c_03453942","updated":"2015-02-11 18:59:37.000000000","message":"Point 1: each scheduler would get the uuid list, and make its own determination if it is in sync or not. Only those that detect a problem would take action to correct.\n\nPoint 2: No, sending the UUIDs would be a fanout cast. If a scheduler found a mis-match, it would then take action to update its view of the instances for that host. It would not necessarily be a call to the compute manager; I think having the scheduler call InstanceList.get_by_host() would be cleaner, but some might feel that that\u0027s too heavy a call, and may opt for the individual instance updates described in the section below dealing with syncing.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c9f11009c6110cb913af97968cdc37dd53f19d2f","unresolved":false,"context_lines":[{"line_number":91,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client"},{"line_number":92,"context_line":"with the action specified as \u0027sync\u0027. This could be added to the"},{"line_number":93,"context_line":"ComputeManager\u0027s update_available_resource() method, since this also runs"},{"line_number":94,"context_line":"periodically."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The update would require that the HostManager locate the entry for the"},{"line_number":97,"context_line":"specified host in its _instance_info dict, and then use the \u0027action\u0027 parameter"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_0015139b","line":94,"in_reply_to":"da86d52c_83004802","updated":"2015-02-12 09:34:20.000000000","message":"I got your point, and I understood it was a fanout cast. That\u0027s the condition where the scheduler is desync that I want to discuss.\n\nIf we revert back the logic to having the Scheduler call the Compute API, then we couldn\u0027t reach what I\u0027m trying to provide, ie. a shared-state optimistic scheduler like Google Omega.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"baecdfe89a5480a516f4534c9d9e4c349feb2fe3","unresolved":false,"context_lines":[{"line_number":91,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client"},{"line_number":92,"context_line":"with the action specified as \u0027sync\u0027. This could be added to the"},{"line_number":93,"context_line":"ComputeManager\u0027s update_available_resource() method, since this also runs"},{"line_number":94,"context_line":"periodically."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The update would require that the HostManager locate the entry for the"},{"line_number":97,"context_line":"specified host in its _instance_info dict, and then use the \u0027action\u0027 parameter"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_cda89422","line":94,"in_reply_to":"da86d52c_83004802","updated":"2015-02-12 11:22:56.000000000","message":"Remember that as Ed says, the sync is only to deal with extraordinary circumstances. I think it\u0027s OK to be a little heavy at this point since this should be so infrequent, EG to retrieve the whole InstanceList.\n\nPlease do correct me if I\u0027m wrong, but since the whole point of this spec is to stop the scheduler peeking at the Nova DB, it sounds like requesting it from the compute node is the only option. This will always be needed as a fallback - the scheduler can use its DB (when it exists) as the primary source of truth, but when exceptional circumstances strike, the compute manager is the only service able to correct a discrepancy.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"358975df363f0bb7663defa7ccefbbbf916ce0f7","unresolved":false,"context_lines":[{"line_number":91,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client"},{"line_number":92,"context_line":"with the action specified as \u0027sync\u0027. This could be added to the"},{"line_number":93,"context_line":"ComputeManager\u0027s update_available_resource() method, since this also runs"},{"line_number":94,"context_line":"periodically."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The update would require that the HostManager locate the entry for the"},{"line_number":97,"context_line":"specified host in its _instance_info dict, and then use the \u0027action\u0027 parameter"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_4227fdc9","line":94,"in_reply_to":"da86d52c_ae6508b0","updated":"2015-02-12 16:27:41.000000000","message":"OK, thanks Alexis for your opinion, I\u0027m leaving Ed implementing this way.\n\nLet\u0027s be clear : Compute periodically provides a list of UUIDs using a ping(host, instance_uuids) where instance_uuids is a list of uuid.uuid4()\n\nThe Scheduler ping() method will then look at HostState and if discrepancy, will call an internal method (for better separatation) which will basically call Instance.get_all_by_host()\n\nFair enough.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"7ba7c059e6ab41a4ff1c864860c90717d807b1bd","unresolved":false,"context_lines":[{"line_number":91,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client"},{"line_number":92,"context_line":"with the action specified as \u0027sync\u0027. This could be added to the"},{"line_number":93,"context_line":"ComputeManager\u0027s update_available_resource() method, since this also runs"},{"line_number":94,"context_line":"periodically."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The update would require that the HostManager locate the entry for the"},{"line_number":97,"context_line":"specified host in its _instance_info dict, and then use the \u0027action\u0027 parameter"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_ae6508b0","line":94,"in_reply_to":"da86d52c_cda89422","updated":"2015-02-12 15:31:32.000000000","message":"+1 Alexis\n\nI really don\u0027t see any other way. The scheduler hits the Nova DB at startup, and then relies on Nova to send updates. Only when there is a failure should the Scheduler have to re-query the Nova DB. I really don\u0027t see any other way to correct a problem, since the Nova DB is the source of truth.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"128b9e3c37eeebb6f77baf45f7fe07eef3284e87","unresolved":false,"context_lines":[{"line_number":91,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client"},{"line_number":92,"context_line":"with the action specified as \u0027sync\u0027. This could be added to the"},{"line_number":93,"context_line":"ComputeManager\u0027s update_available_resource() method, since this also runs"},{"line_number":94,"context_line":"periodically."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The update would require that the HostManager locate the entry for the"},{"line_number":97,"context_line":"specified host in its _instance_info dict, and then use the \u0027action\u0027 parameter"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_f4f54551","line":94,"in_reply_to":"da86d52c_ded865f1","updated":"2015-02-11 16:49:41.000000000","message":"But the sync is *only* uuids, not a full InstanceList. I think this is clearer than sending a list of uuids in the update call, and having the scheduler figure \"Oh, it\u0027s a list of strings, so it must be a sync\".","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"085336843aed7da3a65e87a5d3d682c2b2a8da38","unresolved":false,"context_lines":[{"line_number":91,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client"},{"line_number":92,"context_line":"with the action specified as \u0027sync\u0027. This could be added to the"},{"line_number":93,"context_line":"ComputeManager\u0027s update_available_resource() method, since this also runs"},{"line_number":94,"context_line":"periodically."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"The update would require that the HostManager locate the entry for the"},{"line_number":97,"context_line":"specified host in its _instance_info dict, and then use the \u0027action\u0027 parameter"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_03453942","line":94,"in_reply_to":"da86d52c_f4f54551","updated":"2015-02-11 18:15:02.000000000","message":"Oh I got your idea : you want to send an heartbeat about which instances are running on the host so that it would be lightweight.\n\nWell, the problem is that multiple schedulers don\u0027t necessarly have the same information. Some of them can be out of sync while some others not.\n\nAs it\u0027s not possible (and reasonable) to do a fanout call waiting for a reply, you need to assume that you need to send back to the scheduler(s) the whole list periodically, and not only uuids, because then the scheduler would have to call back the compute manager (which I really want to avoid)","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1fcdfa484bcef5123354c72610cefd5369e31ec9","unresolved":false,"context_lines":[{"line_number":105,"context_line":"            remove it."},{"line_number":106,"context_line":"  * sync:   compare the list of supplied uuids with that of the uuids in the"},{"line_number":107,"context_line":"            corresponding InstanceList, and if they do not match, request"},{"line_number":108,"context_line":"            missing info from the host. See further details below."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The HostManager class\u0027s ``get_all_host_states()``"},{"line_number":111,"context_line":"method would be augmented to add the InstanceList for each host to the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_5e9b9517","line":108,"updated":"2015-02-11 15:19:20.000000000","message":"all of these can be implicit, except the deletion case","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"7ba7c059e6ab41a4ff1c864860c90717d807b1bd","unresolved":false,"context_lines":[{"line_number":105,"context_line":"            remove it."},{"line_number":106,"context_line":"  * sync:   compare the list of supplied uuids with that of the uuids in the"},{"line_number":107,"context_line":"            corresponding InstanceList, and if they do not match, request"},{"line_number":108,"context_line":"            missing info from the host. See further details below."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The HostManager class\u0027s ``get_all_host_states()``"},{"line_number":111,"context_line":"method would be augmented to add the InstanceList for each host to the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_4ed00c1f","line":108,"in_reply_to":"da86d52c_202cd798","updated":"2015-02-12 15:31:32.000000000","message":"I suppose it\u0027s a matter of preference. If the consensus is multiple methods, that will work too, so I have no issue with it.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"128b9e3c37eeebb6f77baf45f7fe07eef3284e87","unresolved":false,"context_lines":[{"line_number":105,"context_line":"            remove it."},{"line_number":106,"context_line":"  * sync:   compare the list of supplied uuids with that of the uuids in the"},{"line_number":107,"context_line":"            corresponding InstanceList, and if they do not match, request"},{"line_number":108,"context_line":"            missing info from the host. See further details below."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The HostManager class\u0027s ``get_all_host_states()``"},{"line_number":111,"context_line":"method would be augmented to add the InstanceList for each host to the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_945ec943","line":108,"in_reply_to":"da86d52c_5e9b9517","updated":"2015-02-11 16:49:41.000000000","message":"Actually, they can all be implicit, if that\u0027s the goal:\n\n - Instance object: create/update\n - Single UUID: delete\n - List of zero or more UUIDs: sync\n\nI think that that\u0027s a very fragile design, which is why I designed it as explicit.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"b7a88ebf9c44e0c04d61a4e0fbba5851265d5567","unresolved":false,"context_lines":[{"line_number":105,"context_line":"            remove it."},{"line_number":106,"context_line":"  * sync:   compare the list of supplied uuids with that of the uuids in the"},{"line_number":107,"context_line":"            corresponding InstanceList, and if they do not match, request"},{"line_number":108,"context_line":"            missing info from the host. See further details below."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The HostManager class\u0027s ``get_all_host_states()``"},{"line_number":111,"context_line":"method would be augmented to add the InstanceList for each host to the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_83d12859","line":108,"in_reply_to":"da86d52c_63a275fd","updated":"2015-02-11 18:59:37.000000000","message":"Distinct methods are no more explicit, but they would require 3 (or 4, if you really want to be explicit and not assume that create and update can be the same call) new RPC methods. I really think that\u0027s overkill; a single RPC method for a host to communicate instance changes is much cleaner. And if your concern is that the resulting method would be too big with multiple conditionals, that could be handled better as part of a code review if the actual code was that poor.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c9f11009c6110cb913af97968cdc37dd53f19d2f","unresolved":false,"context_lines":[{"line_number":105,"context_line":"            remove it."},{"line_number":106,"context_line":"  * sync:   compare the list of supplied uuids with that of the uuids in the"},{"line_number":107,"context_line":"            corresponding InstanceList, and if they do not match, request"},{"line_number":108,"context_line":"            missing info from the host. See further details below."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The HostManager class\u0027s ``get_all_host_states()``"},{"line_number":111,"context_line":"method would be augmented to add the InstanceList for each host to the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_80dd83e2","line":108,"in_reply_to":"da86d52c_83d12859","updated":"2015-02-12 09:34:20.000000000","message":"Well, I don\u0027t want to do bikeshedding, that\u0027s your spec but I\u0027m still thinking it\u0027s better to have distinct methods having different behaviour than just a big method with huge conditionals in there... I leave other reviewers express their own opinions, because I don\u0027t want to block you on that particular point (which is still very important, because we\u0027re designing an API...)","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"baecdfe89a5480a516f4534c9d9e4c349feb2fe3","unresolved":false,"context_lines":[{"line_number":105,"context_line":"            remove it."},{"line_number":106,"context_line":"  * sync:   compare the list of supplied uuids with that of the uuids in the"},{"line_number":107,"context_line":"            corresponding InstanceList, and if they do not match, request"},{"line_number":108,"context_line":"            missing info from the host. See further details below."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The HostManager class\u0027s ``get_all_host_states()``"},{"line_number":111,"context_line":"method would be augmented to add the InstanceList for each host to the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_202cd798","line":108,"in_reply_to":"da86d52c_83d12859","updated":"2015-02-12 11:22:56.000000000","message":"What\u0027s the problem with multiple RPC methods please? AFAIK the main cost here is a one-time back-compatibility fee for extending the API. Adding multiple methods at once is no more costly than adding one.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"085336843aed7da3a65e87a5d3d682c2b2a8da38","unresolved":false,"context_lines":[{"line_number":105,"context_line":"            remove it."},{"line_number":106,"context_line":"  * sync:   compare the list of supplied uuids with that of the uuids in the"},{"line_number":107,"context_line":"            corresponding InstanceList, and if they do not match, request"},{"line_number":108,"context_line":"            missing info from the host. See further details below."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"The HostManager class\u0027s ``get_all_host_states()``"},{"line_number":111,"context_line":"method would be augmented to add the InstanceList for each host to the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_63a275fd","line":108,"in_reply_to":"da86d52c_945ec943","updated":"2015-02-11 18:15:02.000000000","message":"That\u0027s why I\u0027m in favor of distinct methods with no action arg, rather than a big method having multiple conditionals","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1fcdfa484bcef5123354c72610cefd5369e31ec9","unresolved":false,"context_lines":[{"line_number":133,"context_line":"need to send potentially large amounts of data for the update if there are many"},{"line_number":134,"context_line":"instances on the host. The other would be for the HostManager to process the"},{"line_number":135,"context_line":"list of UUIDs, deleting any in its list that are not in the sync list, and then"},{"line_number":136,"context_line":"instantiating Instance objects using that class\u0027s get_by_uuid() method."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Note that both of these approaches will not help the situation where an"},{"line_number":139,"context_line":"instance has been resized and the message to the scheduler was lost. Since the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_7e413962","line":136,"updated":"2015-02-11 15:19:20.000000000","message":"I\u0027m in favor of the former, that\u0027s something we can optimize","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"baecdfe89a5480a516f4534c9d9e4c349feb2fe3","unresolved":false,"context_lines":[{"line_number":133,"context_line":"need to send potentially large amounts of data for the update if there are many"},{"line_number":134,"context_line":"instances on the host. The other would be for the HostManager to process the"},{"line_number":135,"context_line":"list of UUIDs, deleting any in its list that are not in the sync list, and then"},{"line_number":136,"context_line":"instantiating Instance objects using that class\u0027s get_by_uuid() method."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Note that both of these approaches will not help the situation where an"},{"line_number":139,"context_line":"instance has been resized and the message to the scheduler was lost. Since the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_9eb24492","line":136,"in_reply_to":"da86d52c_0092734b","updated":"2015-02-12 11:22:56.000000000","message":"This paragraph is about how we recover when a discrepancy is detected. I\u0027m in favour of requesting a full InstanceList at this time, because 1) although heavyweight, it should only happen once per blue moon; 2) if an instance create/destroy has gone missing, it\u0027s possible the same EG network failure caused an instance update to go missing.\n\nThat said, I wouldn\u0027t hold up the spec if everyone else is happy with only requesting Instance objects for missing/extra UUIDs.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"085336843aed7da3a65e87a5d3d682c2b2a8da38","unresolved":false,"context_lines":[{"line_number":133,"context_line":"need to send potentially large amounts of data for the update if there are many"},{"line_number":134,"context_line":"instances on the host. The other would be for the HostManager to process the"},{"line_number":135,"context_line":"list of UUIDs, deleting any in its list that are not in the sync list, and then"},{"line_number":136,"context_line":"instantiating Instance objects using that class\u0027s get_by_uuid() method."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Note that both of these approaches will not help the situation where an"},{"line_number":139,"context_line":"instance has been resized and the message to the scheduler was lost. Since the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_a3962d92","line":136,"in_reply_to":"da86d52c_571d3361","updated":"2015-02-11 18:15:02.000000000","message":"See my comment above, the problem is that if you\u0027re only passing heartbeats, then the Scheduler has to call back Nova which is bad IMHO.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c9f11009c6110cb913af97968cdc37dd53f19d2f","unresolved":false,"context_lines":[{"line_number":133,"context_line":"need to send potentially large amounts of data for the update if there are many"},{"line_number":134,"context_line":"instances on the host. The other would be for the HostManager to process the"},{"line_number":135,"context_line":"list of UUIDs, deleting any in its list that are not in the sync list, and then"},{"line_number":136,"context_line":"instantiating Instance objects using that class\u0027s get_by_uuid() method."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Note that both of these approaches will not help the situation where an"},{"line_number":139,"context_line":"instance has been resized and the message to the scheduler was lost. Since the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_0092734b","line":136,"in_reply_to":"da86d52c_63fd14b1","updated":"2015-02-12 09:34:20.000000000","message":"Yeah, I was +1 on providing a regular update of all instances UUIDs, but I just think we should provide the instances, and not leave the Scheduler call back the Compute API. Of course, it doesn\u0027t necessarly need to be done every 60 secs...\nAn ideal world would be to have all the schedulers having the same sync\u0027d HostManager so that we could just call one Scheduler and get the instances uuids for the host so we could give it back a new InstanceList if not good, but that\u0027s not possible.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"128b9e3c37eeebb6f77baf45f7fe07eef3284e87","unresolved":false,"context_lines":[{"line_number":133,"context_line":"need to send potentially large amounts of data for the update if there are many"},{"line_number":134,"context_line":"instances on the host. The other would be for the HostManager to process the"},{"line_number":135,"context_line":"list of UUIDs, deleting any in its list that are not in the sync list, and then"},{"line_number":136,"context_line":"instantiating Instance objects using that class\u0027s get_by_uuid() method."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Note that both of these approaches will not help the situation where an"},{"line_number":139,"context_line":"instance has been resized and the message to the scheduler was lost. Since the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_571d3361","line":136,"in_reply_to":"da86d52c_7e413962","updated":"2015-02-11 16:49:41.000000000","message":"There is a lot of future optimization potential that people felt needed to be addressed from the outset; i.e., that for a large deployment, the overhead for the full InstanceList approach would be prohibitive. I think the former is a better design, but I can\u0027t ignore the opinions of those who feel that passing Nova objects across RPC is too heavyweight.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"358975df363f0bb7663defa7ccefbbbf916ce0f7","unresolved":false,"context_lines":[{"line_number":133,"context_line":"need to send potentially large amounts of data for the update if there are many"},{"line_number":134,"context_line":"instances on the host. The other would be for the HostManager to process the"},{"line_number":135,"context_line":"list of UUIDs, deleting any in its list that are not in the sync list, and then"},{"line_number":136,"context_line":"instantiating Instance objects using that class\u0027s get_by_uuid() method."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Note that both of these approaches will not help the situation where an"},{"line_number":139,"context_line":"instance has been resized and the message to the scheduler was lost. Since the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_fd07b415","line":136,"in_reply_to":"da86d52c_8e9124f3","updated":"2015-02-12 16:27:41.000000000","message":"Agreed, we can discuss that on the implementation patch","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"d078058f951ea4c25b3c13717be8516e069e2de1","unresolved":false,"context_lines":[{"line_number":133,"context_line":"need to send potentially large amounts of data for the update if there are many"},{"line_number":134,"context_line":"instances on the host. The other would be for the HostManager to process the"},{"line_number":135,"context_line":"list of UUIDs, deleting any in its list that are not in the sync list, and then"},{"line_number":136,"context_line":"instantiating Instance objects using that class\u0027s get_by_uuid() method."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Note that both of these approaches will not help the situation where an"},{"line_number":139,"context_line":"instance has been resized and the message to the scheduler was lost. Since the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_5d7a7fba","line":136,"in_reply_to":"da86d52c_8e9124f3","updated":"2015-02-12 17:03:38.000000000","message":"Yes I agree sending an InstanceList regularly is a bad idea. For a host that is not in sync, it gives you the most healing capability.\n\nI think we\u0027re all in agreement here now, at least to iron this out totally during impl.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"7ba7c059e6ab41a4ff1c864860c90717d807b1bd","unresolved":false,"context_lines":[{"line_number":133,"context_line":"need to send potentially large amounts of data for the update if there are many"},{"line_number":134,"context_line":"instances on the host. The other would be for the HostManager to process the"},{"line_number":135,"context_line":"list of UUIDs, deleting any in its list that are not in the sync list, and then"},{"line_number":136,"context_line":"instantiating Instance objects using that class\u0027s get_by_uuid() method."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Note that both of these approaches will not help the situation where an"},{"line_number":139,"context_line":"instance has been resized and the message to the scheduler was lost. Since the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_8e9124f3","line":136,"in_reply_to":"da86d52c_9eb24492","updated":"2015-02-12 15:31:32.000000000","message":"I strongly think that sending complete InstanceList objects for every host periodically, even if it is a longer period than 60 seconds, is a code smell. If the regular updates work well, this should never be needed. If sending such a huge amount of information regularly is needed, then the whole update process sucks and should be fixed.\n\nAlexis: I prefer the full InstanceList for a host that is not in sync, but I was anticipating that some might still see that as too heavyweight, and wanted to provide that option. We hadn\u0027t discussed this aspect of the spec at either the midcycle or the last Gantt meeting.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"b7a88ebf9c44e0c04d61a4e0fbba5851265d5567","unresolved":false,"context_lines":[{"line_number":133,"context_line":"need to send potentially large amounts of data for the update if there are many"},{"line_number":134,"context_line":"instances on the host. The other would be for the HostManager to process the"},{"line_number":135,"context_line":"list of UUIDs, deleting any in its list that are not in the sync list, and then"},{"line_number":136,"context_line":"instantiating Instance objects using that class\u0027s get_by_uuid() method."},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"Note that both of these approaches will not help the situation where an"},{"line_number":139,"context_line":"instance has been resized and the message to the scheduler was lost. Since the"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_63fd14b1","line":136,"in_reply_to":"da86d52c_a3962d92","updated":"2015-02-11 18:59:37.000000000","message":"And if every compute node passes its full InstanceList over RPC once a minute, that\u0027s very bad, too.\n\nThis was discussed both at the midcycle and in yesterday\u0027s IRC meeting. From the log:\n\n  15:47:06 \u003cn0ano\u003e then, just to be clear, do we all agree on edleafe proposed steps:\n  15:47:08 \u003cn0ano\u003e - go back to previous design (discussed at midcycle)\n  15:47:08 \u003cn0ano\u003e - change it to add an incremental update for changed instances\n  15:47:08 \u003cn0ano\u003e - add a regular update of all UUIDs that scheduler can use to chaeck for snc problems\n  15:47:08 \u003cn0ano\u003e - add a way for scheduler to ask for updates to missing/extra instance\n  15:47:16 \u003clxsli\u003e +1\n  15:47:20 \u003cjaypipes\u003e +1\n  15:47:26 \u003cndipanov\u003e I guess\n  15:47:30 \u003cndipanov\u003e +1\n  15:47:34 \u003cbauzas\u003e that sounds reasonable\n  15:47:35 \u003cbauzas\u003e +1\n  15:47:47 \u003calex_xu_\u003e +1","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1fcdfa484bcef5123354c72610cefd5369e31ec9","unresolved":false,"context_lines":[{"line_number":142,"context_line":""},{"line_number":143,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":144,"context_line":"be added to the ComputeManager class called"},{"line_number":145,"context_line":"``_update_scheduler_instance_info()``. This would call the scheduler client"},{"line_number":146,"context_line":"with the instance in question, and the appropriate action being taken on that"},{"line_number":147,"context_line":"instance. The scheduler client would then make the RPC fanout call to pass this"},{"line_number":148,"context_line":"information on to all running schedulers. The ComputeManager would have to have"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_5e1e3571","line":145,"updated":"2015-02-11 15:19:20.000000000","message":"is that a typo or a miss ? I don\u0027t see the difference with the former update_instance_info() method that you exposed previously ?","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"128b9e3c37eeebb6f77baf45f7fe07eef3284e87","unresolved":false,"context_lines":[{"line_number":142,"context_line":""},{"line_number":143,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":144,"context_line":"be added to the ComputeManager class called"},{"line_number":145,"context_line":"``_update_scheduler_instance_info()``. This would call the scheduler client"},{"line_number":146,"context_line":"with the instance in question, and the appropriate action being taken on that"},{"line_number":147,"context_line":"instance. The scheduler client would then make the RPC fanout call to pass this"},{"line_number":148,"context_line":"information on to all running schedulers. The ComputeManager would have to have"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_77a7970b","line":145,"in_reply_to":"da86d52c_5e1e3571","updated":"2015-02-11 16:49:41.000000000","message":"It\u0027s an oversight. At the midcycle people felt that \u0027_update_scheduler_instance_info\u0027 was clearer, so I changed it to the longer name. The reference above should also be changed.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"085336843aed7da3a65e87a5d3d682c2b2a8da38","unresolved":false,"context_lines":[{"line_number":142,"context_line":""},{"line_number":143,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":144,"context_line":"be added to the ComputeManager class called"},{"line_number":145,"context_line":"``_update_scheduler_instance_info()``. This would call the scheduler client"},{"line_number":146,"context_line":"with the instance in question, and the appropriate action being taken on that"},{"line_number":147,"context_line":"instance. The scheduler client would then make the RPC fanout call to pass this"},{"line_number":148,"context_line":"information on to all running schedulers. The ComputeManager would have to have"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_e38ca582","line":145,"in_reply_to":"da86d52c_77a7970b","updated":"2015-02-11 18:15:02.000000000","message":"Ok, I leave you updating the above then","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"c9f11009c6110cb913af97968cdc37dd53f19d2f","unresolved":false,"context_lines":[{"line_number":142,"context_line":""},{"line_number":143,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":144,"context_line":"be added to the ComputeManager class called"},{"line_number":145,"context_line":"``_update_scheduler_instance_info()``. This would call the scheduler client"},{"line_number":146,"context_line":"with the instance in question, and the appropriate action being taken on that"},{"line_number":147,"context_line":"instance. The scheduler client would then make the RPC fanout call to pass this"},{"line_number":148,"context_line":"information on to all running schedulers. The ComputeManager would have to have"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_a0ffe732","line":145,"in_reply_to":"da86d52c_83904844","updated":"2015-02-12 09:34:20.000000000","message":"My bad then, I\u0027m OK with that","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"b7a88ebf9c44e0c04d61a4e0fbba5851265d5567","unresolved":false,"context_lines":[{"line_number":142,"context_line":""},{"line_number":143,"context_line":"In order to keep the information in the scheduler current, a new method would"},{"line_number":144,"context_line":"be added to the ComputeManager class called"},{"line_number":145,"context_line":"``_update_scheduler_instance_info()``. This would call the scheduler client"},{"line_number":146,"context_line":"with the instance in question, and the appropriate action being taken on that"},{"line_number":147,"context_line":"instance. The scheduler client would then make the RPC fanout call to pass this"},{"line_number":148,"context_line":"information on to all running schedulers. The ComputeManager would have to have"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_83904844","line":145,"in_reply_to":"da86d52c_e38ca582","updated":"2015-02-11 18:59:37.000000000","message":"Wait - I think I read too fast. There are two separate methods with different names.\n\n1) ComputeManager._update_scheduler_instance_info() - called internally in the compute manager by its methods when instance status changes in a way that should be passed on to the scheduler.\n\n2) SchedulerClient.update_instance_info() - called by ComputeManager to pass the update to the scheduler. It is a public method, and doesn\u0027t need the redundant \u0027scheduler\u0027 part in its name, since it is a method of the scheduler client.\n\nSo looking back above, the naming is correct.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1fcdfa484bcef5123354c72610cefd5369e31ec9","unresolved":false,"context_lines":[{"line_number":156,"context_line":""},{"line_number":157,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":158,"context_line":"the action has succeeded, and the Instance object has all of its attributes"},{"line_number":159,"context_line":"populated, before making the call to update the scheduler."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"Many deployments do not use any of these filters, so they don\u0027t need for their"},{"line_number":162,"context_line":"scheduler to have current information about the instances. It would be wasteful"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_69050110","line":159,"updated":"2015-02-11 15:19:20.000000000","message":"+1 on that paragraph, except the confusion with the method name","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"dc4961feeb17d5fa114b7abe356867f204f6076f","unresolved":false,"context_lines":[{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new integer column will be added to the compute_nodes table to hold the"},{"line_number":217,"context_line":"version that the compute node understands. It will default to 0, and any"},{"line_number":218,"context_line":"compute nodes that run this version of nova will update their value to 1."},{"line_number":219,"context_line":"Future updates to the behavior of compute nodes will increment the version, so"},{"line_number":220,"context_line":"that rolling deployments consisting of mixed compute node versions can be"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_f005687a","line":217,"updated":"2015-02-11 08:36:29.000000000","message":"How about just use RPC version for this column? We already have rpc version, then we needn\u0027t invent another method to count the compute node version.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"b99a8a12f647112356ed9a15ba44aa4e4aa06dc5","unresolved":false,"context_lines":[{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new integer column will be added to the compute_nodes table to hold the"},{"line_number":217,"context_line":"version that the compute node understands. It will default to 0, and any"},{"line_number":218,"context_line":"compute nodes that run this version of nova will update their value to 1."},{"line_number":219,"context_line":"Future updates to the behavior of compute nodes will increment the version, so"},{"line_number":220,"context_line":"that rolling deployments consisting of mixed compute node versions can be"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_4c6acb81","line":217,"in_reply_to":"da86d52c_2fa120f8","updated":"2015-02-12 18:14:12.000000000","message":"Now that I\u0027m writing this up, it occurs to me that we might not need to change the DB at all here. Once Sylvain\u0027s patch to make HostManager use ComputeNode objects gets merged (https://review.openstack.org/#/c/138294/), we can see the version of the compute node there. I\u0027ll be bumping that up to \u00271.11\u0027 with this change, so I can check for \u003e\u003d 1.1.\n\nDoes that sound like a better approach?","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"baecdfe89a5480a516f4534c9d9e4c349feb2fe3","unresolved":false,"context_lines":[{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new integer column will be added to the compute_nodes table to hold the"},{"line_number":217,"context_line":"version that the compute node understands. It will default to 0, and any"},{"line_number":218,"context_line":"compute nodes that run this version of nova will update their value to 1."},{"line_number":219,"context_line":"Future updates to the behavior of compute nodes will increment the version, so"},{"line_number":220,"context_line":"that rolling deployments consisting of mixed compute node versions can be"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_2fa120f8","line":217,"in_reply_to":"da86d52c_5b9ba717","updated":"2015-02-12 11:22:56.000000000","message":"+1 making this more generally useful, seems a big win for little effort","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1fcdfa484bcef5123354c72610cefd5369e31ec9","unresolved":false,"context_lines":[{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new integer column will be added to the compute_nodes table to hold the"},{"line_number":217,"context_line":"version that the compute node understands. It will default to 0, and any"},{"line_number":218,"context_line":"compute nodes that run this version of nova will update their value to 1."},{"line_number":219,"context_line":"Future updates to the behavior of compute nodes will increment the version, so"},{"line_number":220,"context_line":"that rolling deployments consisting of mixed compute node versions can be"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_69534117","line":217,"in_reply_to":"da86d52c_5b9ba717","updated":"2015-02-11 15:19:20.000000000","message":"That\u0027s something we can tackle in the implementation as a detail","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"694f9c65a57d599d5e279ec8658cd90c74ff1afd","unresolved":false,"context_lines":[{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new integer column will be added to the compute_nodes table to hold the"},{"line_number":217,"context_line":"version that the compute node understands. It will default to 0, and any"},{"line_number":218,"context_line":"compute nodes that run this version of nova will update their value to 1."},{"line_number":219,"context_line":"Future updates to the behavior of compute nodes will increment the version, so"},{"line_number":220,"context_line":"that rolling deployments consisting of mixed compute node versions can be"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_b5dbd4eb","line":217,"in_reply_to":"da86d52c_9a235ebc","updated":"2015-02-11 14:17:09.000000000","message":"yes, I know that. I just think maybe we can store the rpc version directly in the new column, not just 0 and 1. That maybe useful for the future. Anyway it\u0027s enough for now. we can discussion this later.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"81df1fae62362386ae3247dc71782fa7b3a97372","unresolved":false,"context_lines":[{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new integer column will be added to the compute_nodes table to hold the"},{"line_number":217,"context_line":"version that the compute node understands. It will default to 0, and any"},{"line_number":218,"context_line":"compute nodes that run this version of nova will update their value to 1."},{"line_number":219,"context_line":"Future updates to the behavior of compute nodes will increment the version, so"},{"line_number":220,"context_line":"that rolling deployments consisting of mixed compute node versions can be"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_5b9ba717","line":217,"in_reply_to":"da86d52c_b5dbd4eb","updated":"2015-02-11 14:54:46.000000000","message":"Ah, sorry, I misunderstood what you were asking. At the mid-cycle we discussed this, and decided that a simple incrementing integer should suffice. But I do like the idea of using the RPC version.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"6079b602ce8a1045cd922f9a8efb7149f128f85b","unresolved":false,"context_lines":[{"line_number":214,"context_line":"-----------------"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"A new integer column will be added to the compute_nodes table to hold the"},{"line_number":217,"context_line":"version that the compute node understands. It will default to 0, and any"},{"line_number":218,"context_line":"compute nodes that run this version of nova will update their value to 1."},{"line_number":219,"context_line":"Future updates to the behavior of compute nodes will increment the version, so"},{"line_number":220,"context_line":"that rolling deployments consisting of mixed compute node versions can be"}],"source_content_type":"text/x-rst","patch_set":22,"id":"da86d52c_9a235ebc","line":217,"in_reply_to":"da86d52c_f005687a","updated":"2015-02-11 13:37:59.000000000","message":"Because if updates are rolled out to compute nodes, some will have the previous version that did not update the scheduler with instance changes, and those running newer versions will be updating. The scheduler will have no way of knowing when filtering hosts if the list of instances they have is current (because it\u0027s being updated by a newer node), or old (because that node hasn\u0027t received the update yet). The column in the compute_nodes table will enable the scheduler to distinguish between the two, and handle those cases differently.","commit_id":"f9f1fa0f3ee402335685288ab926c5bffabb3cdb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5cfc82bbad68a32c438a6c7b40a2e7c26b72d534","unresolved":false,"context_lines":[{"line_number":111,"context_line":"instance will be sent. This would be done via 2 new RPC API methods for the"},{"line_number":112,"context_line":"scheduler. For create/update, the following method will be added:"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"  - update_instance_info(context, host_name, instance_or_list)"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"For terminated instances, the following method will be added:"},{"line_number":117,"context_line":""}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_bd7197e0","line":114,"updated":"2015-02-13 10:39:10.000000000","message":"Are we really needing to pass out the context ? I don\u0027t think so as we don\u0027t need to call out the DB","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a6315162eb3d895101c815a53d5223bcaaadfb17","unresolved":false,"context_lines":[{"line_number":111,"context_line":"instance will be sent. This would be done via 2 new RPC API methods for the"},{"line_number":112,"context_line":"scheduler. For create/update, the following method will be added:"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"  - update_instance_info(context, host_name, instance_or_list)"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"For terminated instances, the following method will be added:"},{"line_number":117,"context_line":""}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_0b4414b6","line":114,"in_reply_to":"da86d52c_bd7197e0","updated":"2015-02-13 14:09:09.000000000","message":"There is always the case that the Scheduler receives an update from a host that it doesn\u0027t have in its view. In that case, as well as when a sync fails, it will have to recreate the full InstanceList for the host, and that needs the context.","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5cfc82bbad68a32c438a6c7b40a2e7c26b72d534","unresolved":false,"context_lines":[{"line_number":169,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client."},{"line_number":170,"context_line":"The following RPC API method will be added for this purpose:"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"  - sync_instance_info(context, host_name, instance_uuids)"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"This could be added to the ComputeManager\u0027s update_available_resource() method,"},{"line_number":175,"context_line":"since this also runs periodically, or, if this is felt to be too chatty, a"}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_dd2c8baf","line":172,"updated":"2015-02-13 10:39:10.000000000","message":"nit: I\u0027m seeing this method as an hearbeat, so I was thinking about ping_instance_info(). Technically, it\u0027s not a sync method (which is why I was previously confused) because you\u0027re not uploading data and sync\u0027ing it.","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a6315162eb3d895101c815a53d5223bcaaadfb17","unresolved":false,"context_lines":[{"line_number":169,"context_line":"create a list of their instances\u0027 UUIDs, and pass that to the scheduler client."},{"line_number":170,"context_line":"The following RPC API method will be added for this purpose:"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"  - sync_instance_info(context, host_name, instance_uuids)"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"This could be added to the ComputeManager\u0027s update_available_resource() method,"},{"line_number":175,"context_line":"since this also runs periodically, or, if this is felt to be too chatty, a"}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_c66593e3","line":172,"in_reply_to":"da86d52c_dd2c8baf","updated":"2015-02-13 14:09:09.000000000","message":"It\u0027s not technically a heartbeat, either. It\u0027s providing a way for the Scheduler to verify that things are in sync. A heartbeat would simply tell the Scheduler that that host is still running.","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5cfc82bbad68a32c438a6c7b40a2e7c26b72d534","unresolved":false,"context_lines":[{"line_number":173,"context_line":""},{"line_number":174,"context_line":"This could be added to the ComputeManager\u0027s update_available_resource() method,"},{"line_number":175,"context_line":"since this also runs periodically, or, if this is felt to be too chatty, a"},{"line_number":176,"context_line":"separate period for syncing instance uuids could be created."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"When the Scheduler receives this sync notification, it will construct the list"},{"line_number":179,"context_line":"of uuids in the HostManager\u0027s _instance_info attribute for the specified"}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_5807c918","line":176,"updated":"2015-02-13 10:39:10.000000000","message":"I\u0027m in favor of a separate period, but that\u0027s a nit","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a6315162eb3d895101c815a53d5223bcaaadfb17","unresolved":false,"context_lines":[{"line_number":173,"context_line":""},{"line_number":174,"context_line":"This could be added to the ComputeManager\u0027s update_available_resource() method,"},{"line_number":175,"context_line":"since this also runs periodically, or, if this is felt to be too chatty, a"},{"line_number":176,"context_line":"separate period for syncing instance uuids could be created."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"When the Scheduler receives this sync notification, it will construct the list"},{"line_number":179,"context_line":"of uuids in the HostManager\u0027s _instance_info attribute for the specified"}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_068ecb79","line":176,"in_reply_to":"da86d52c_5807c918","updated":"2015-02-13 14:09:09.000000000","message":"It\u0027s a possibility for a future optimization. All sync failures are logged, so we can see how often they occur in production, and adjust accordingly.","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5cfc82bbad68a32c438a6c7b40a2e7c26b72d534","unresolved":false,"context_lines":[{"line_number":182,"context_line":"there has been some unusual interruption of the normal update process, and that"},{"line_number":183,"context_line":"the view of the instances for that host_name is not valid. It would be best to"},{"line_number":184,"context_line":"simply have the Scheduler call InstanceList.get_by_host() and then replace the"},{"line_number":185,"context_line":"InstanceList in the HostManager._instance_info for that host with the retrieved"},{"line_number":186,"context_line":"values. It could also be possible to have the Scheduler retrieve individual"},{"line_number":187,"context_line":"Instance objects for the uuids in the notification that are not in the"},{"line_number":188,"context_line":"HostManager, and delete the instances that are in HostManager but not it the"}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_58a34900","line":185,"updated":"2015-02-13 10:39:10.000000000","message":"something comes in my mind about concurrent transactions to HostManager. Couldn\u0027t we maybe provide a semaphore on top of the update methods so that we\u0027re sure that while a _resync() method is occuring, all the other updates coming from the RPCAPI are blocked ?","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a6315162eb3d895101c815a53d5223bcaaadfb17","unresolved":false,"context_lines":[{"line_number":182,"context_line":"there has been some unusual interruption of the normal update process, and that"},{"line_number":183,"context_line":"the view of the instances for that host_name is not valid. It would be best to"},{"line_number":184,"context_line":"simply have the Scheduler call InstanceList.get_by_host() and then replace the"},{"line_number":185,"context_line":"InstanceList in the HostManager._instance_info for that host with the retrieved"},{"line_number":186,"context_line":"values. It could also be possible to have the Scheduler retrieve individual"},{"line_number":187,"context_line":"Instance objects for the uuids in the notification that are not in the"},{"line_number":188,"context_line":"HostManager, and delete the instances that are in HostManager but not it the"}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_e620d7fa","line":185,"in_reply_to":"da86d52c_58a34900","updated":"2015-02-13 14:09:09.000000000","message":"Sure, that\u0027s a good idea.","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5cfc82bbad68a32c438a6c7b40a2e7c26b72d534","unresolved":false,"context_lines":[{"line_number":227,"context_line":"the HostManager will check the ComputeNode object retrieved in its"},{"line_number":228,"context_line":"get_all_host_states() call, to see if the VERSION attribute is at least the"},{"line_number":229,"context_line":"version set in this release (currently 1.1, but that could change by the time"},{"line_number":230,"context_line":"these changes merge). If it is running a version earlier than that (and thus"},{"line_number":231,"context_line":"would not be sending updates), the HostManager would revert to the current"},{"line_number":232,"context_line":"behavior of direct DB/API calls to get that information. Instead of doing it in"},{"line_number":233,"context_line":"the filters, though, the HostManager would call InstanceList.get_by_host(), and"}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_b8d7e54e","line":230,"updated":"2015-02-13 10:39:10.000000000","message":"As I said in the later PS, as it is done by the Scheduler, then the ComputeNode version is the same for all the computenodes, even for Juno ones so that doesn\u0027t work.","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a6315162eb3d895101c815a53d5223bcaaadfb17","unresolved":false,"context_lines":[{"line_number":227,"context_line":"the HostManager will check the ComputeNode object retrieved in its"},{"line_number":228,"context_line":"get_all_host_states() call, to see if the VERSION attribute is at least the"},{"line_number":229,"context_line":"version set in this release (currently 1.1, but that could change by the time"},{"line_number":230,"context_line":"these changes merge). If it is running a version earlier than that (and thus"},{"line_number":231,"context_line":"would not be sending updates), the HostManager would revert to the current"},{"line_number":232,"context_line":"behavior of direct DB/API calls to get that information. Instead of doing it in"},{"line_number":233,"context_line":"the filters, though, the HostManager would call InstanceList.get_by_host(), and"}],"source_content_type":"text/x-rst","patch_set":25,"id":"da86d52c_c16f3d92","line":230,"in_reply_to":"da86d52c_b8d7e54e","updated":"2015-02-13 14:09:09.000000000","message":"\u003csigh\u003e That\u0027s what I get for rushing this out. You\u0027re right; this won\u0027t work. I\u0027ll add back the database changes. What do you think about Alex Xu\u0027s suggestion of having the column store the RPC version? Would that be a more generic solution?","commit_id":"d12e6f247a0bb35ba7e98712794b98b20c3780b3"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"6c34209b5b0c657107fd0390d365179fc72efef1","unresolved":false,"context_lines":[{"line_number":124,"context_line":"  * _build_and_run_instance() - when a new instance is created"},{"line_number":125,"context_line":"  * _complete_deletion()      - when an instance is destroyed"},{"line_number":126,"context_line":"  * _finish_resize()          - when an instance is resized"},{"line_number":127,"context_line":"  * shelve_offload_instance() - when a shelved instance is destroyed"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":130,"context_line":"the action has succeeded, and the Instance object has all of its attributes"}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_ba6cf809","line":127,"updated":"2015-02-16 13:16:22.000000000","message":"missing one for live migration","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a82eec6f93235f9dd0b618eb6b2fd60db1d88894","unresolved":false,"context_lines":[{"line_number":124,"context_line":"  * _build_and_run_instance() - when a new instance is created"},{"line_number":125,"context_line":"  * _complete_deletion()      - when an instance is destroyed"},{"line_number":126,"context_line":"  * _finish_resize()          - when an instance is resized"},{"line_number":127,"context_line":"  * shelve_offload_instance() - when a shelved instance is destroyed"},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"All of the calls would come at the end of these methods, when we are sure that"},{"line_number":130,"context_line":"the action has succeeded, and the Instance object has all of its attributes"}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_b398a36b","line":127,"in_reply_to":"da86d52c_ba6cf809","updated":"2015-02-16 14:30:51.000000000","message":"Done","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":1981,"name":"Don Dugger","email":"n0ano@n0ano.com","username":"n0ano"},"change_message_id":"f9b7f0cb89ee6cce681eaaa2cb226e9fbdda6a2b","unresolved":false,"context_lines":[{"line_number":172,"context_line":"  - sync_instance_info(context, host_name, instance_uuids)"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"This could be added to the ComputeManager\u0027s update_available_resource() method,"},{"line_number":175,"context_line":"since this also runs periodically, or, if this is felt to be too chatty, a"},{"line_number":176,"context_line":"separate period for syncing instance uuids could be created."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"When the Scheduler receives this sync notification, it will construct the list"}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_7c728ee4","line":175,"updated":"2015-02-16 03:23:19.000000000","message":"In an attempt to cut down on unnecessary messages we changed the periodic update code to only send updates when something changes  so the sync won\u0027t be able to piggy back on the resource updates, we\u0027ll have to use our own periodic timer.  I\u0027m not a fan of unnecessary messages that are sent `just in case`, they have negative impacts on scalability so I\u0027d prefer we keep this code well separated so it can be removed if we decide it\u0027s not needed later.","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a82eec6f93235f9dd0b618eb6b2fd60db1d88894","unresolved":false,"context_lines":[{"line_number":172,"context_line":"  - sync_instance_info(context, host_name, instance_uuids)"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"This could be added to the ComputeManager\u0027s update_available_resource() method,"},{"line_number":175,"context_line":"since this also runs periodically, or, if this is felt to be too chatty, a"},{"line_number":176,"context_line":"separate period for syncing instance uuids could be created."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"When the Scheduler receives this sync notification, it will construct the list"}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_13c40f40","line":175,"in_reply_to":"da86d52c_7c728ee4","updated":"2015-02-16 14:30:51.000000000","message":"OK, that\u0027s a good point. I\u0027ll separate it out.","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":1981,"name":"Don Dugger","email":"n0ano@n0ano.com","username":"n0ano"},"change_message_id":"f9b7f0cb89ee6cce681eaaa2cb226e9fbdda6a2b","unresolved":false,"context_lines":[{"line_number":185,"context_line":"InstanceList in the HostManager._instance_info for that host with the retrieved"},{"line_number":186,"context_line":"values. It could also be possible to have the Scheduler retrieve individual"},{"line_number":187,"context_line":"Instance objects for the uuids in the notification that are not in the"},{"line_number":188,"context_line":"HostManager, and delete the instances that are in HostManager but not it the"},{"line_number":189,"context_line":"notification, but if we are in an obvious error state, it would be better to"},{"line_number":190,"context_line":"start fresh and be sure that the two versions are in sync."},{"line_number":191,"context_line":""}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_5c0a2a28","line":188,"updated":"2015-02-16 03:23:19.000000000","message":"Small nit (only if there\u0027s a new version of the spec) - s/not it the/not in the/","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a82eec6f93235f9dd0b618eb6b2fd60db1d88894","unresolved":false,"context_lines":[{"line_number":185,"context_line":"InstanceList in the HostManager._instance_info for that host with the retrieved"},{"line_number":186,"context_line":"values. It could also be possible to have the Scheduler retrieve individual"},{"line_number":187,"context_line":"Instance objects for the uuids in the notification that are not in the"},{"line_number":188,"context_line":"HostManager, and delete the instances that are in HostManager but not it the"},{"line_number":189,"context_line":"notification, but if we are in an obvious error state, it would be better to"},{"line_number":190,"context_line":"start fresh and be sure that the two versions are in sync."},{"line_number":191,"context_line":""}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_b30b437c","line":188,"in_reply_to":"da86d52c_5c0a2a28","updated":"2015-02-16 14:30:51.000000000","message":"Done","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":1981,"name":"Don Dugger","email":"n0ano@n0ano.com","username":"n0ano"},"change_message_id":"f9b7f0cb89ee6cce681eaaa2cb226e9fbdda6a2b","unresolved":false,"context_lines":[{"line_number":212,"context_line":"Opting Out of Instance Notification"},{"line_number":213,"context_line":"-----------------------------------"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"Many deployments do not use any of these filters, so they don\u0027t need for their"},{"line_number":216,"context_line":"scheduler to have current information about the instances. It would be wasteful"},{"line_number":217,"context_line":"to have them constantly sending information that will never be used, so we will"},{"line_number":218,"context_line":"add a new CONF setting that will default to True. If a deployer knows that"}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_3f2488ae","line":215,"updated":"2015-02-16 03:23:19.000000000","message":"Grammar nit (only if there\u0027s a new version of the spec) - s/so they don\u0027t need for their/so they don\u0027t need the/","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a82eec6f93235f9dd0b618eb6b2fd60db1d88894","unresolved":false,"context_lines":[{"line_number":212,"context_line":"Opting Out of Instance Notification"},{"line_number":213,"context_line":"-----------------------------------"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"Many deployments do not use any of these filters, so they don\u0027t need for their"},{"line_number":216,"context_line":"scheduler to have current information about the instances. It would be wasteful"},{"line_number":217,"context_line":"to have them constantly sending information that will never be used, so we will"},{"line_number":218,"context_line":"add a new CONF setting that will default to True. If a deployer knows that"}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_937b9ff3","line":215,"in_reply_to":"da86d52c_3f2488ae","updated":"2015-02-16 14:30:51.000000000","message":"Done","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"6c34209b5b0c657107fd0390d365179fc72efef1","unresolved":false,"context_lines":[{"line_number":229,"context_line":"current information about the instances on a compute node, since pre-Kilo nodes"},{"line_number":230,"context_line":"will not be doing the updates described in the above paragraph. To handle this,"},{"line_number":231,"context_line":"a new string column will be added to the compute_nodes table that will hold the"},{"line_number":232,"context_line":"current RPC version for the compute manager. This value will default to \u00270\u0027 if"},{"line_number":233,"context_line":"it is not populated. Compute nodes running Kilo will update that column to"},{"line_number":234,"context_line":"their current RPC version upon startup. The HostManager would then check this"},{"line_number":235,"context_line":"when adding instance information to the HostState objects.  If the compute node"}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_fdf74ad2","line":232,"updated":"2015-02-16 13:16:22.000000000","message":"++ for rpc version","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":1981,"name":"Don Dugger","email":"n0ano@n0ano.com","username":"n0ano"},"change_message_id":"f9b7f0cb89ee6cce681eaaa2cb226e9fbdda6a2b","unresolved":false,"context_lines":[{"line_number":236,"context_line":"has an RPC version less than the value at the Kilo release (and thus would not"},{"line_number":237,"context_line":"be sending updates), the HostManager would revert to the current behavior of"},{"line_number":238,"context_line":"direct DB/API calls to get that information. Instead of doing it in the"},{"line_number":239,"context_line":"filters, though, the HostManager would call InstanceList.get_by_host(), and add"},{"line_number":240,"context_line":"that instance information to the HostState object. As the nodes get updated and"},{"line_number":241,"context_line":"restarted, they will start sending updates, and the HostManager will no longer"},{"line_number":242,"context_line":"need to make those InstanceList calls, and instead will be able to use the"}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_9f6014d1","line":239,"updated":"2015-02-16 03:23:19.000000000","message":"What triggers the HostManager to call InstanceList.get_by_host?  Since the HostManager doesn\u0027t know which filters are being called it doesn\u0027t know when this update is needed.","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"a82eec6f93235f9dd0b618eb6b2fd60db1d88894","unresolved":false,"context_lines":[{"line_number":236,"context_line":"has an RPC version less than the value at the Kilo release (and thus would not"},{"line_number":237,"context_line":"be sending updates), the HostManager would revert to the current behavior of"},{"line_number":238,"context_line":"direct DB/API calls to get that information. Instead of doing it in the"},{"line_number":239,"context_line":"filters, though, the HostManager would call InstanceList.get_by_host(), and add"},{"line_number":240,"context_line":"that instance information to the HostState object. As the nodes get updated and"},{"line_number":241,"context_line":"restarted, they will start sending updates, and the HostManager will no longer"},{"line_number":242,"context_line":"need to make those InstanceList calls, and instead will be able to use the"}],"source_content_type":"text/x-rst","patch_set":26,"id":"da86d52c_13716fde","line":239,"in_reply_to":"da86d52c_9f6014d1","updated":"2015-02-16 14:30:51.000000000","message":"See the last line of the \u0027Opting out of Instance Notification\u0027 section above. I envision the HostManager using this CONF setting to control its behavior. I\u0027ve expanded the first item in the Work Items section to make this clearer.","commit_id":"bba3eea9929aa5603569107db7bffd9ae0cc4621"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3e56d11bc60ad6ceeef1cc8545d7c3f6860ca1ea","unresolved":false,"context_lines":[{"line_number":111,"context_line":"instance will be sent. This would be done via 2 new RPC API methods for the"},{"line_number":112,"context_line":"scheduler. For create/update, the following method will be added:"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"  - update_instance_info(context, host_name, instance_or_list)"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"For terminated instances, the following method will be added:"},{"line_number":117,"context_line":""}],"source_content_type":"text/x-rst","patch_set":27,"id":"da86d52c_44405635","line":114,"updated":"2015-02-17 14:02:11.000000000","message":"Saw your reply but I prefer to comment it again for the replies :\n\nso, I don\u0027t think we need to pass the context. I know that select_dest() is doing this, but I don\u0027t think it\u0027s a good thing. I mean, we should just say that if the scheduler is querying the DB, it should be done by its context, not the user context so we could just call context.get_admin_context() if we need to call out the DB.\n\nHere, I don\u0027t see an added value to add the context, so I\u0027m leaving -1 until someone one either accepts my view or refuses my view (I don\u0027t want to nitpick but that\u0027s again something important as this is an API signature)","commit_id":"31c1e24a97b8b1967475d6b53ca4a1304ef93861"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"4e9dda6aba59aa7832915c2ccaabdb65f9f94e01","unresolved":false,"context_lines":[{"line_number":158,"context_line":"    database. Stripping this down to just the data that is needed now will mean"},{"line_number":159,"context_line":"    more work later on."},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"Adding Periodic Sync Sanity Checks"},{"line_number":162,"context_line":"----------------------------------"},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"We must also take into account the fact that occasionally messages from a"}],"source_content_type":"text/x-rst","patch_set":27,"id":"da86d52c_829b4265","line":161,"updated":"2015-02-16 17:24:46.000000000","message":"femtonit: the most detail-oriented of us will notice you\u0027re jumping between initial-caps and normal case for subsection headings","commit_id":"31c1e24a97b8b1967475d6b53ca4a1304ef93861"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"4e9dda6aba59aa7832915c2ccaabdb65f9f94e01","unresolved":false,"context_lines":[{"line_number":220,"context_line":"Compute nodes will read this setting at startup, and if it is False, they will"},{"line_number":221,"context_line":"not update the scheduler when their instances change, nor send periodic sync"},{"line_number":222,"context_line":"messages. Similarly, the HostManager would see this setting and know not to"},{"line_number":223,"context_line":"bother to add instance information to the HostState objects."},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"Handling Rolling Updates to Compute Nodes"},{"line_number":226,"context_line":"-----------------------------------------"}],"source_content_type":"text/x-rst","patch_set":27,"id":"da86d52c_c2829aa4","line":223,"updated":"2015-02-16 17:24:46.000000000","message":"nit: or, presumably, to initialise the cache on startup.","commit_id":"31c1e24a97b8b1967475d6b53ca4a1304ef93861"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3e56d11bc60ad6ceeef1cc8545d7c3f6860ca1ea","unresolved":false,"context_lines":[{"line_number":231,"context_line":"a new string column will be added to the compute_nodes table that will hold the"},{"line_number":232,"context_line":"current RPC version for the compute manager. This value will default to \u00270\u0027 if"},{"line_number":233,"context_line":"it is not populated. Compute nodes running Kilo will update that column to"},{"line_number":234,"context_line":"their current RPC version upon startup. The HostManager would then check this"},{"line_number":235,"context_line":"when adding instance information to the HostState objects.  If the compute node"},{"line_number":236,"context_line":"has an RPC version less than the value at the Kilo release (and thus would not"},{"line_number":237,"context_line":"be sending updates), the HostManager would revert to the current behavior of"}],"source_content_type":"text/x-rst","patch_set":27,"id":"da86d52c_a4b3d24b","line":234,"updated":"2015-02-17 14:02:11.000000000","message":"That looks good to me","commit_id":"31c1e24a97b8b1967475d6b53ca4a1304ef93861"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"4e9dda6aba59aa7832915c2ccaabdb65f9f94e01","unresolved":false,"context_lines":[{"line_number":235,"context_line":"when adding instance information to the HostState objects.  If the compute node"},{"line_number":236,"context_line":"has an RPC version less than the value at the Kilo release (and thus would not"},{"line_number":237,"context_line":"be sending updates), the HostManager would revert to the current behavior of"},{"line_number":238,"context_line":"direct DB/API calls to get that information. Instead of doing it in the"},{"line_number":239,"context_line":"filters, though, the HostManager would call InstanceList.get_by_host(), and add"},{"line_number":240,"context_line":"that instance information to the HostState object. As the nodes get updated and"},{"line_number":241,"context_line":"restarted, they will start sending updates, and the HostManager will no longer"}],"source_content_type":"text/x-rst","patch_set":27,"id":"da86d52c_e2a87e22","line":238,"updated":"2015-02-16 17:24:46.000000000","message":"nit: might be clearer to say \"just in time\" rather than \"direct\" ? Just a thought","commit_id":"31c1e24a97b8b1967475d6b53ca4a1304ef93861"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"4e9dda6aba59aa7832915c2ccaabdb65f9f94e01","unresolved":false,"context_lines":[{"line_number":261,"context_line":"Data model impact"},{"line_number":262,"context_line":"-----------------"},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"None."},{"line_number":265,"context_line":""},{"line_number":266,"context_line":"REST API impact"},{"line_number":267,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":27,"id":"da86d52c_081a11c6","line":264,"updated":"2015-02-16 17:24:46.000000000","message":"\"a new string column will be added to the compute_nodes table that will hold the current RPC version for the compute manager\"","commit_id":"31c1e24a97b8b1967475d6b53ca4a1304ef93861"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"4e9dda6aba59aa7832915c2ccaabdb65f9f94e01","unresolved":false,"context_lines":[{"line_number":293,"context_line":"Other deployer impact"},{"line_number":294,"context_line":"---------------------"},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"None."},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"Developer impact"},{"line_number":299,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":27,"id":"da86d52c_e84cddca","line":296,"updated":"2015-02-16 17:24:46.000000000","message":"Deployers need to be told about the option to disable update_instance_info et al","commit_id":"31c1e24a97b8b1967475d6b53ca4a1304ef93861"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"9f240b57a7023e82ed0469e34648f9530fcdc8fb","unresolved":false,"context_lines":[{"line_number":83,"context_line":"    to Nova will now base their filtering decisions on the information in the"},{"line_number":84,"context_line":"    HostState objects instead."},{"line_number":85,"context_line":"  - Some deployments do not use filters that require instance information, and"},{"line_number":86,"context_line":"    need to be able to turn off all of this behavior."},{"line_number":87,"context_line":"  - Allow for differing behaviors during rolling updates."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Changes to the Scheduler Startup"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_511b3880","line":86,"updated":"2015-02-26 15:11:21.000000000","message":"Turning this off has to be the same as turning the filter off and on, otherwise there is no way for a user who also reads the filters code to know which options need to be turned on at the same time.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f90c1d0f3ce9d097936f67f51b4f8be87516eaaa","unresolved":false,"context_lines":[{"line_number":83,"context_line":"    to Nova will now base their filtering decisions on the information in the"},{"line_number":84,"context_line":"    HostState objects instead."},{"line_number":85,"context_line":"  - Some deployments do not use filters that require instance information, and"},{"line_number":86,"context_line":"    need to be able to turn off all of this behavior."},{"line_number":87,"context_line":"  - Allow for differing behaviors during rolling updates."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Changes to the Scheduler Startup"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_ae4dea3f","line":86,"in_reply_to":"ba7be1f8_511b3880","updated":"2015-02-26 17:37:47.000000000","message":"Yes, the proposed method is to have the compute manager look at the nova.conf list of activated scheduler filters (which is the same way that the scheduler side uses to load filter plugins).","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"b13ccf4e9c59335703c1fc58f1911ea8c0bb4219","unresolved":false,"context_lines":[{"line_number":83,"context_line":"    to Nova will now base their filtering decisions on the information in the"},{"line_number":84,"context_line":"    HostState objects instead."},{"line_number":85,"context_line":"  - Some deployments do not use filters that require instance information, and"},{"line_number":86,"context_line":"    need to be able to turn off all of this behavior."},{"line_number":87,"context_line":"  - Allow for differing behaviors during rolling updates."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Changes to the Scheduler Startup"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_a404294a","line":86,"in_reply_to":"ba7be1f8_ae4dea3f","updated":"2015-02-26 18:06:54.000000000","message":"Nikola, have you reconsidered this now you know instance info messages are always sent by default? IMO if an operator is smart enough to turn off the instance info messages, they should be smart enough to turn them back on if they start using a filter that needs them.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"6032281751b3b914b42ff9cb4e5b646cb76c2c0a","unresolved":false,"context_lines":[{"line_number":86,"context_line":"    need to be able to turn off all of this behavior."},{"line_number":87,"context_line":"  - Allow for differing behaviors during rolling updates."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Changes to the Scheduler Startup"},{"line_number":90,"context_line":"--------------------------------"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"The initial population of the instance information would be done when the"}],"source_content_type":"text/x-rst","patch_set":28,"id":"da86d52c_bfed74f2","line":89,"updated":"2015-02-18 11:16:15.000000000","message":"Bless you for fixing these","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":1981,"name":"Don Dugger","email":"n0ano@n0ano.com","username":"n0ano"},"change_message_id":"03e09cba5b23cc1086b10605a40ffd28d9188ff4","unresolved":false,"context_lines":[{"line_number":86,"context_line":"    need to be able to turn off all of this behavior."},{"line_number":87,"context_line":"  - Allow for differing behaviors during rolling updates."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Changes to the Scheduler Startup"},{"line_number":90,"context_line":"--------------------------------"},{"line_number":91,"context_line":""},{"line_number":92,"context_line":"The initial population of the instance information would be done when the"}],"source_content_type":"text/x-rst","patch_set":28,"id":"da86d52c_4ce3dd33","line":89,"in_reply_to":"da86d52c_bfed74f2","updated":"2015-02-19 17:20:10.000000000","message":"Done","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f90c1d0f3ce9d097936f67f51b4f8be87516eaaa","unresolved":false,"context_lines":[{"line_number":170,"context_line":"  - The design for how this information is used will be much closer to what it"},{"line_number":171,"context_line":"    will be when we separate the scheduler into its own service with its own"},{"line_number":172,"context_line":"    database. Stripping this down to just the data that is needed now will mean"},{"line_number":173,"context_line":"    more work later on."},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"Adding Periodic Sync Sanity Checks"},{"line_number":176,"context_line":"----------------------------------"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_ee4c42ca","line":173,"updated":"2015-02-26 17:37:47.000000000","message":"++ on above. very well defined.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f90c1d0f3ce9d097936f67f51b4f8be87516eaaa","unresolved":false,"context_lines":[{"line_number":187,"context_line":"  - sync_instance_info(context, host_name, instance_uuids)"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"This would be called as a periodic task, with a new CONF setting to handle the"},{"line_number":190,"context_line":"frequency."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"When the Scheduler receives this sync notification, it will construct the list"},{"line_number":193,"context_line":"of uuids in the HostManager\u0027s _instance_info attribute for the specified"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_ce869eb8","line":190,"updated":"2015-02-26 17:37:47.000000000","message":"I don\u0027t think this needs a new CONF setting. There is already a periodic CONF interval used by sync_compute_node(). I\u0027d just use that...","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"e4dbe8b3837a96407143966fb2bd77c4ff15bc80","unresolved":false,"context_lines":[{"line_number":187,"context_line":"  - sync_instance_info(context, host_name, instance_uuids)"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"This would be called as a periodic task, with a new CONF setting to handle the"},{"line_number":190,"context_line":"frequency."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"When the Scheduler receives this sync notification, it will construct the list"},{"line_number":193,"context_line":"of uuids in the HostManager\u0027s _instance_info attribute for the specified"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_fa515830","line":190,"in_reply_to":"ba7be1f8_ce869eb8","updated":"2015-02-26 19:02:32.000000000","message":"Jay: I had originally tied it to an existing periodic task, but the consensus was that we don\u0027t know now how often things would be out of sync, so they wanted the option to set this higher or lower at some point in the future.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"b13ccf4e9c59335703c1fc58f1911ea8c0bb4219","unresolved":false,"context_lines":[{"line_number":187,"context_line":"  - sync_instance_info(context, host_name, instance_uuids)"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"This would be called as a periodic task, with a new CONF setting to handle the"},{"line_number":190,"context_line":"frequency."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"When the Scheduler receives this sync notification, it will construct the list"},{"line_number":193,"context_line":"of uuids in the HostManager\u0027s _instance_info attribute for the specified"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_048a5563","line":190,"in_reply_to":"ba7be1f8_ce869eb8","updated":"2015-02-26 18:06:54.000000000","message":"Not sure how often that is, but I think we might want this to be less frequent? We could perhaps use a multiple of it.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f90c1d0f3ce9d097936f67f51b4f8be87516eaaa","unresolved":false,"context_lines":[{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Since a host can continue to send updates while the HostManager is recreating"},{"line_number":207,"context_line":"the InstanceList, all of the methods that can change the view of a host will be"},{"line_number":208,"context_line":"decorated with a semaphore lock to avoid contentions."},{"line_number":209,"context_line":""},{"line_number":210,"context_line":"Note that neither of these approaches will help the situation where an instance"},{"line_number":211,"context_line":"has been resized and the message to the scheduler was lost. Since the UUIDs in"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_ae0eca38","line":208,"updated":"2015-02-26 17:37:47.000000000","message":"++","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"9f240b57a7023e82ed0469e34648f9530fcdc8fb","unresolved":false,"context_lines":[{"line_number":235,"context_line":"not update the scheduler when their instances change, nor send periodic sync"},{"line_number":236,"context_line":"messages. Similarly, the HostManager would see this setting and know not to"},{"line_number":237,"context_line":"bother to create the instance cache at startup, nor add instance information to"},{"line_number":238,"context_line":"the HostState objects."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Handling Rolling Updates to Compute Nodes"},{"line_number":241,"context_line":"-----------------------------------------"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_c2df5867","line":238,"updated":"2015-02-26 15:11:21.000000000","message":"This sounds really error prone for the deployers. How about we have a way for hosts to discover weather to send the info. That way adding a filter to the scheduler will not require rolling restart of all compute services.\n\nIMHO this is a huge bane on user experience unless changed.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"e4dbe8b3837a96407143966fb2bd77c4ff15bc80","unresolved":false,"context_lines":[{"line_number":235,"context_line":"not update the scheduler when their instances change, nor send periodic sync"},{"line_number":236,"context_line":"messages. Similarly, the HostManager would see this setting and know not to"},{"line_number":237,"context_line":"bother to create the instance cache at startup, nor add instance information to"},{"line_number":238,"context_line":"the HostState objects."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Handling Rolling Updates to Compute Nodes"},{"line_number":241,"context_line":"-----------------------------------------"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_883817d6","line":238,"in_reply_to":"ba7be1f8_098a7063","updated":"2015-02-26 19:02:32.000000000","message":"Jay: Assuming that the compute nodes can accurately gauge this based on active filters (which assumes that only these 3 filters will ever use instance information), it may turn out that this is too heavy memory-wise for some deployments, and that they may want to turn it off, which will cause the scheduler to issue DB queries with each scheduling request, more or less as it does now.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"b13ccf4e9c59335703c1fc58f1911ea8c0bb4219","unresolved":false,"context_lines":[{"line_number":235,"context_line":"not update the scheduler when their instances change, nor send periodic sync"},{"line_number":236,"context_line":"messages. Similarly, the HostManager would see this setting and know not to"},{"line_number":237,"context_line":"bother to create the instance cache at startup, nor add instance information to"},{"line_number":238,"context_line":"the HostState objects."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Handling Rolling Updates to Compute Nodes"},{"line_number":241,"context_line":"-----------------------------------------"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_e92d1ca9","line":238,"in_reply_to":"ba7be1f8_098a7063","updated":"2015-02-26 18:06:54.000000000","message":"You\u0027re assuming the scheduler filter list is written to the nova.conf on compute nodes. This has not previously been required.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"44e5b2bfbcae9f79efa5aabfcaf3e4facac94aaf","unresolved":false,"context_lines":[{"line_number":235,"context_line":"not update the scheduler when their instances change, nor send periodic sync"},{"line_number":236,"context_line":"messages. Similarly, the HostManager would see this setting and know not to"},{"line_number":237,"context_line":"bother to create the instance cache at startup, nor add instance information to"},{"line_number":238,"context_line":"the HostState objects."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Handling Rolling Updates to Compute Nodes"},{"line_number":241,"context_line":"-----------------------------------------"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_e8da7d76","line":238,"in_reply_to":"ba7be1f8_c2df5867","updated":"2015-02-26 15:47:40.000000000","message":"Ok after speaking with lxsli - this really means - send it by default unless you really want to turn it off.\n\nEven though I hate the fact that we have a config option - this does not sound too horrible.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"f90c1d0f3ce9d097936f67f51b4f8be87516eaaa","unresolved":false,"context_lines":[{"line_number":235,"context_line":"not update the scheduler when their instances change, nor send periodic sync"},{"line_number":236,"context_line":"messages. Similarly, the HostManager would see this setting and know not to"},{"line_number":237,"context_line":"bother to create the instance cache at startup, nor add instance information to"},{"line_number":238,"context_line":"the HostState objects."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Handling Rolling Updates to Compute Nodes"},{"line_number":241,"context_line":"-----------------------------------------"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_098a7063","line":238,"in_reply_to":"ba7be1f8_e8da7d76","updated":"2015-02-26 17:37:47.000000000","message":"I don\u0027t understand why we need a separate CONF option for this. Why not just examine the list of active filters in the nova.conf on both the scheduler and compute nodes?","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":8688,"name":"Alexis Lee","email":"openstack@lxsli.co.uk","username":"lxsli"},"change_message_id":"6032281751b3b914b42ff9cb4e5b646cb76c2c0a","unresolved":false,"context_lines":[{"line_number":244,"context_line":"scheduler is updated, we also need to handle the situation where we do not have"},{"line_number":245,"context_line":"current information about the instances on a compute node, since pre-Kilo nodes"},{"line_number":246,"context_line":"will not be doing the instance information updates described above. Without"},{"line_number":247,"context_line":"those updates, we can\u0027t rely on the version of the InstanceList in the"},{"line_number":248,"context_line":"HostManager, so we must query the DB each time there is a scheduling request."},{"line_number":249,"context_line":"To track this, the entry for each host in the _instance_info attribute will"},{"line_number":250,"context_line":"have a value that is a two-element dict: one to hold the InstanceList, and the"}],"source_content_type":"text/x-rst","patch_set":28,"id":"da86d52c_df6f885e","line":247,"updated":"2015-02-18 11:16:15.000000000","message":"nit: s/version of the //","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"713a6b381f66bdecfd283fda20dd6c48bc0dfe98","unresolved":false,"context_lines":[{"line_number":249,"context_line":"To track this, the entry for each host in the _instance_info attribute will"},{"line_number":250,"context_line":"have a value that is a two-element dict: one to hold the InstanceList, and the"},{"line_number":251,"context_line":"other to hold a status indicator. This value will be set initially to False,"},{"line_number":252,"context_line":"meaning that we don\u0027t yet know whether the compute node is running a version of"},{"line_number":253,"context_line":"software that will properly update the scheduler with its instance changes."},{"line_number":254,"context_line":"Once we receive an update/delete/sync message from a host, we know that it is"},{"line_number":255,"context_line":"running at least a minimal version to trust the Scheduler\u0027s view of the"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_aad71222","line":252,"updated":"2015-02-24 11:37:23.000000000","message":"I\u0027m maybe not 100% OK with your strategy heren but let\u0027s leave those kinds of nitty gritty details to the patches.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"9f240b57a7023e82ed0469e34648f9530fcdc8fb","unresolved":false,"context_lines":[{"line_number":253,"context_line":"software that will properly update the scheduler with its instance changes."},{"line_number":254,"context_line":"Once we receive an update/delete/sync message from a host, we know that it is"},{"line_number":255,"context_line":"running at least a minimal version to trust the Scheduler\u0027s view of the"},{"line_number":256,"context_line":"instances, and we can use that for the filters."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"This design will mean that some extra calls to the DB to get InstanceLists will"},{"line_number":259,"context_line":"be needed when the Scheduler first starts up, as it will not yet be able to"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_026b3085","line":256,"updated":"2015-02-26 15:11:21.000000000","message":"We could change this to use the feature probing messages I mention above.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"962a2295b533b71d96d68399d0a5e57bc90a2831","unresolved":false,"context_lines":[{"line_number":253,"context_line":"software that will properly update the scheduler with its instance changes."},{"line_number":254,"context_line":"Once we receive an update/delete/sync message from a host, we know that it is"},{"line_number":255,"context_line":"running at least a minimal version to trust the Scheduler\u0027s view of the"},{"line_number":256,"context_line":"instances, and we can use that for the filters."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"This design will mean that some extra calls to the DB to get InstanceLists will"},{"line_number":259,"context_line":"be needed when the Scheduler first starts up, as it will not yet be able to"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_ddd819f1","line":256,"in_reply_to":"ba7be1f8_026b3085","updated":"2015-02-26 15:40:29.000000000","message":"One more thought on this. How about using the upgrade_levels to control this? the upside is that it will be much simpler, the downside is that the new awesomeness won\u0027t work for deployers until they upgrade the whole cloud.\n\nI think that under the circumstances this is a better tradeof since the point of this work is to lay the foundation for the future, not necessarily bring a new feature (although it will improve perf in theory).","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":5511,"name":"Nikola Dipanov","email":"ndipanov@redhat.com","username":"ndipanov"},"change_message_id":"9f240b57a7023e82ed0469e34648f9530fcdc8fb","unresolved":false,"context_lines":[{"line_number":273,"context_line":"be taken so that any changes to the hosts themselves are also propagated to the"},{"line_number":274,"context_line":"scheduler.  But while this would be overall a cleaner approach and more in line"},{"line_number":275,"context_line":"with where we want to take the scheduler, it was felt that this exceeded the"},{"line_number":276,"context_line":"scope of the current blueprints."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Data model impact"},{"line_number":279,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_620b0cd6","line":276,"updated":"2015-02-26 15:11:21.000000000","message":"This sentence keeps weirding me out :) the alternative is better but we won\u0027t do it :) no action needed on this one though just commenting.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"e4dbe8b3837a96407143966fb2bd77c4ff15bc80","unresolved":false,"context_lines":[{"line_number":273,"context_line":"be taken so that any changes to the hosts themselves are also propagated to the"},{"line_number":274,"context_line":"scheduler.  But while this would be overall a cleaner approach and more in line"},{"line_number":275,"context_line":"with where we want to take the scheduler, it was felt that this exceeded the"},{"line_number":276,"context_line":"scope of the current blueprints."},{"line_number":277,"context_line":""},{"line_number":278,"context_line":"Data model impact"},{"line_number":279,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":28,"id":"ba7be1f8_88ad77ed","line":276,"in_reply_to":"ba7be1f8_620b0cd6","updated":"2015-02-26 19:02:32.000000000","message":"I put this in because it was what I had originally proposed, but was rejected as not covered by the BP. It is closer to what we envision the separated scheduler service might implement.","commit_id":"dee5d5e26a28e5c6cb977821326f405e54d742eb"}]}