)]}'
{"releasenotes/notes/agg-resource-filters-6e24c92a69afa85f.yaml":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"292ac4a449f4421b71a6ae29987b4ff7b1938a49","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Starting in Ocata, there is a behavior change where aggregate-based"},{"line_number":5,"context_line":"    overcommit ratios will no longer be honored during scheduling for the"},{"line_number":6,"context_line":"    FilterScheduler. Instead, overcommit values must be set on a"},{"line_number":7,"context_line":"    per-compute-node basis in the Nova configuration files."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    If you have been relying on per-aggregate overcommit, during your upgrade,"}],"source_content_type":"text/x-yaml","patch_set":1,"id":"3fa0c359_209ae613","line":6,"range":{"start_line":6,"start_character":4,"end_line":6,"end_character":19},"updated":"2018-02-05 21:46:07.000000000","message":"FilterScheduler and it\u0027s subclasses such as the CachingScheduler.\n\nmgagne said they were using the CachingScheduler which made me think about this.","commit_id":"1c4d2f4cbdf096cbd79297338cfb40d15875f930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"8cd55e965a38f82ca202af362e83a650618c9ec6","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Starting in Ocata, there is a behavior change where aggregate-based"},{"line_number":5,"context_line":"    overcommit ratios will no longer be honored during scheduling for the"},{"line_number":6,"context_line":"    FilterScheduler. Instead, overcommit values must be set on a"},{"line_number":7,"context_line":"    per-compute-node basis in the Nova configuration files."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    If you have been relying on per-aggregate overcommit, during your upgrade,"}],"source_content_type":"text/x-yaml","patch_set":1,"id":"3fa0c359_2713c6b7","line":6,"range":{"start_line":6,"start_character":19,"end_line":6,"end_character":20},"updated":"2018-02-06 17:47:39.000000000","message":"I\u0027d have clarified:\n\"if you use the FilterScheduler scheduler driver which is the default driver\".","commit_id":"1c4d2f4cbdf096cbd79297338cfb40d15875f930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c13862582e7e3bcca805095e90676c5cfdd08d0a","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Starting in Ocata, there is a behavior change where aggregate-based"},{"line_number":5,"context_line":"    overcommit ratios will no longer be honored during scheduling for the"},{"line_number":6,"context_line":"    FilterScheduler. Instead, overcommit values must be set on a"},{"line_number":7,"context_line":"    per-compute-node basis in the Nova configuration files."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    If you have been relying on per-aggregate overcommit, during your upgrade,"}],"source_content_type":"text/x-yaml","patch_set":1,"id":"3fa0c359_cf832d04","line":6,"range":{"start_line":6,"start_character":4,"end_line":6,"end_character":19},"in_reply_to":"3fa0c359_004c8a9c","updated":"2018-02-06 01:31:24.000000000","message":"Yeah good point, ignore me about the CachingScheduler, which might actually be the saving grace for mgagne.","commit_id":"1c4d2f4cbdf096cbd79297338cfb40d15875f930"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"0b5ae0a0bcd08ecba5b21b84d6bc3036f4958221","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Starting in Ocata, there is a behavior change where aggregate-based"},{"line_number":5,"context_line":"    overcommit ratios will no longer be honored during scheduling for the"},{"line_number":6,"context_line":"    FilterScheduler. Instead, overcommit values must be set on a"},{"line_number":7,"context_line":"    per-compute-node basis in the Nova configuration files."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    If you have been relying on per-aggregate overcommit, during your upgrade,"}],"source_content_type":"text/x-yaml","patch_set":1,"id":"3fa0c359_004c8a9c","line":6,"range":{"start_line":6,"start_character":4,"end_line":6,"end_character":19},"in_reply_to":"3fa0c359_209ae613","updated":"2018-02-05 21:50:50.000000000","message":"Hm, I wouldn\u0027t have expected the CachingScheduler to be affected by this because it\u0027s the new placement query pruning that makes the Aggregate\u003cResource\u003eFilters obsolete. That is, the placement query does not take aggregate-based overcommit into account. And I thought the CachingScheduler did *not* have the placement prune query:\n\nhttps://github.com/openstack/nova/blob/stable/ocata/nova/scheduler/filter_scheduler.py#L183","commit_id":"1c4d2f4cbdf096cbd79297338cfb40d15875f930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"8cd55e965a38f82ca202af362e83a650618c9ec6","unresolved":false,"context_lines":[{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    Starting in Ocata, there is a behavior change where aggregate-based"},{"line_number":5,"context_line":"    overcommit ratios will no longer be honored during scheduling for the"},{"line_number":6,"context_line":"    FilterScheduler. Instead, overcommit values must be set on a"},{"line_number":7,"context_line":"    per-compute-node basis in the Nova configuration files."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    If you have been relying on per-aggregate overcommit, during your upgrade,"}],"source_content_type":"text/x-yaml","patch_set":1,"id":"3fa0c359_4714d2a0","line":6,"range":{"start_line":6,"start_character":4,"end_line":6,"end_character":19},"in_reply_to":"3fa0c359_cf832d04","updated":"2018-02-06 17:47:39.000000000","message":"Since only FilterScheduler calls Placement, yeah it\u0027s only impacting that scheduler driver.","commit_id":"1c4d2f4cbdf096cbd79297338cfb40d15875f930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"fee7680f5aec1d89634da545d094e6e5c1a3d18a","unresolved":false,"context_lines":[{"line_number":16,"context_line":"    AggregateDiskFilter from your ``[filter_scheduler]enabled_filters`` and you"},{"line_number":17,"context_line":"    do not need to replace them with any other core/ram/disk filters. The"},{"line_number":18,"context_line":"    placement query in the FilterScheduler takes care of the core/ram/disk"},{"line_number":19,"context_line":"    filtering, so CoreFilter, RamFilter, and DiskFilter are redundant."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Please see the mailing list thread for more information:"},{"line_number":22,"context_line":"    http://lists.openstack.org/pipermail/openstack-operators/2018-January/014748.html"}],"source_content_type":"text/x-yaml","patch_set":1,"id":"3fa0c359_67678e4f","line":19,"range":{"start_line":19,"start_character":17,"end_line":19,"end_character":70},"updated":"2018-02-06 17:48:34.000000000","message":"we already deprecated them since Ocata FWIW (again, unless if you use CachingScheduler).","commit_id":"1c4d2f4cbdf096cbd79297338cfb40d15875f930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"1ffaabb8a6cc1eaf8b77c12ec9f94f00648c5b84","unresolved":false,"context_lines":[{"line_number":17,"context_line":"    do not need to replace them with any other core/ram/disk filters. The"},{"line_number":18,"context_line":"    placement query in the FilterScheduler takes care of the core/ram/disk"},{"line_number":19,"context_line":"    filtering, so CoreFilter, RamFilter, and DiskFilter are redundant."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Please see the mailing list thread for more information:"},{"line_number":22,"context_line":"    http://lists.openstack.org/pipermail/openstack-operators/2018-January/014748.html"}],"source_content_type":"text/x-yaml","patch_set":1,"id":"3fa0c359_a78fd6ca","line":20,"updated":"2018-02-06 17:57:21.000000000","message":"Just a note : if operators set on each compute allocation ratios of 9999.0 for CPU, RAM and disk, Placement will not check the resource usage for those resource classes and pass all the nodes down to the FilterScheduler. In that case, AggregateRAMFilter and others could correctly work","commit_id":"1c4d2f4cbdf096cbd79297338cfb40d15875f930"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4fa90f7d0816b26961ba80f6e2fb0220d06b0e53","unresolved":false,"context_lines":[{"line_number":17,"context_line":"    do not need to replace them with any other core/ram/disk filters. The"},{"line_number":18,"context_line":"    placement query in the FilterScheduler takes care of the core/ram/disk"},{"line_number":19,"context_line":"    filtering, so CoreFilter, RamFilter, and DiskFilter are redundant."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"    Please see the mailing list thread for more information:"},{"line_number":22,"context_line":"    http://lists.openstack.org/pipermail/openstack-operators/2018-January/014748.html"}],"source_content_type":"text/x-yaml","patch_set":1,"id":"3fa0c359_619c375d","line":20,"in_reply_to":"3fa0c359_a78fd6ca","updated":"2018-02-07 18:59:57.000000000","message":"Yes ... but the goal of this release note is to alert operators that they will get changed behavior when they upgrade, if they are relying on these filters and are using the FilterScheduler. They will have to take action to avoid undesired behavior.\n\nI\u0027m not sure we want to recommend setting all compute node nova.conf ratios to 9999.0 in this doc. The currently supported way to set different ratios is to set them per compute node nova.conf and some possible solutions for the future are being discussed on the ML thread.","commit_id":"1c4d2f4cbdf096cbd79297338cfb40d15875f930"}]}