)]}'
{"specs/liberty/approved/config-scheduler-filter.rst":[{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"88c7ecb0416125afc71b33125c8f2d511df9295c","unresolved":false,"context_lines":[{"line_number":37,"context_line":"Project Priority"},{"line_number":38,"context_line":"-----------------"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"These are undefined, as of yet."},{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Proposed change"},{"line_number":43,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3afb71cf_91f077ca","line":40,"range":{"start_line":40,"start_character":6,"end_line":40,"end_character":9},"updated":"2015-06-11 05:21:28.000000000","message":"They\u0027ve now been defined.","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"},{"author":{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},"change_message_id":"b3c5ff14a70a576a8b05cced522d8664fd596657","unresolved":false,"context_lines":[{"line_number":43,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"I propose a \"config filter\" or \"newbie filter\" that can be enabled by"},{"line_number":46,"context_line":"default, and positioned to run first in the sequence. This filter will"},{"line_number":47,"context_line":"examine a boot request, and compare it against the system"},{"line_number":48,"context_line":"configuration (and potentially other details) to cause a fast fail of"},{"line_number":49,"context_line":"the request with a helpful fault message."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7aaa499b_7a7320e8","line":46,"updated":"2015-04-14 15:27:04.000000000","message":"Will this be enabled by default? I don\u0027t think so. I am not sure how \u0027heavy\u0027 these checks will be.\n\nCould it be something that is invoked dynamically. Say I have my cloud running an boom things stop working - could be a misconfiguration value on upgrade. Having a scheuler hint that could invoke this could be great - then you do not cause the admin headaches with configs","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"},{"author":{"_account_id":6062,"name":"jichenjc","email":"jichenjc@cn.ibm.com","username":"jichenjc"},"change_message_id":"5ad5512c6449cf7aeed39038842c676385aa03b8","unresolved":false,"context_lines":[{"line_number":43,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"I propose a \"config filter\" or \"newbie filter\" that can be enabled by"},{"line_number":46,"context_line":"default, and positioned to run first in the sequence. This filter will"},{"line_number":47,"context_line":"examine a boot request, and compare it against the system"},{"line_number":48,"context_line":"configuration (and potentially other details) to cause a fast fail of"},{"line_number":49,"context_line":"the request with a helpful fault message."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7aaa499b_fa160df0","line":46,"updated":"2015-04-14 16:18:34.000000000","message":"are we going to do it like:\ncheck all hosts we have and whether they support numa? \nagree it might be too expensive\n\nand if we really need to check whether scheduler enable PIC filter or NUMA filter, we don\u0027t need a config filter\nwe can directly check at scheduler client module","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c0f698f0d778ccb3f8171df9c4687dcd05a38799","unresolved":false,"context_lines":[{"line_number":43,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"I propose a \"config filter\" or \"newbie filter\" that can be enabled by"},{"line_number":46,"context_line":"default, and positioned to run first in the sequence. This filter will"},{"line_number":47,"context_line":"examine a boot request, and compare it against the system"},{"line_number":48,"context_line":"configuration (and potentially other details) to cause a fast fail of"},{"line_number":49,"context_line":"the request with a helpful fault message."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7aaa499b_490f5288","line":46,"in_reply_to":"7aaa499b_fa160df0","updated":"2015-04-15 17:05:56.000000000","message":"As I said in the text, this should be a thing we can have enabled by default. No, it should not be any checks so heavy as to have to examine the numa-ness of all the hosts. However, checking that the numa filter is enabled and rejecting a request that specifies a numa requirement is an easy/fast check.","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"},{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"88c7ecb0416125afc71b33125c8f2d511df9295c","unresolved":false,"context_lines":[{"line_number":55,"context_line":"* An attempt to boot an instance with a prescribed NUMA topology, when"},{"line_number":56,"context_line":"  the NUMA scheduler filter is not enabled"},{"line_number":57,"context_line":"* An attempt to boot an instance with a PCI request, when the PCI"},{"line_number":58,"context_line":"  scheduler filter is not enabled"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"By running first and quickly, this filter can fail the boot request"},{"line_number":61,"context_line":"early and set the instance state and fault message to something"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3afb71cf_919e3761","line":58,"updated":"2015-06-11 05:21:28.000000000","message":"I\u0027m a bit concerned that this fast fail filter will get out of sync with filters as they change over time. Would it be better to add a pre-flight call to each filter which we could call at the start of a schedule attempt? That would serve the same purpose, but would keep the code for the pre-flight checks with the filter code.","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"},{"author":{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},"change_message_id":"b3c5ff14a70a576a8b05cced522d8664fd596657","unresolved":false,"context_lines":[{"line_number":62,"context_line":"helpful, such as:"},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"  \"You requested a PCI device, but this deployment is not configured"},{"line_number":65,"context_line":"  for PCI passthrough.\""},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Alternatives"},{"line_number":68,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7aaa499b_7afe8039","line":65,"updated":"2015-04-14 15:27:04.000000000","message":"One thing that I am missing here is that the configurations which may cause the problems are on the nova compute nodes and they are not on the scheduler node. How will this help?\n\nBugs that I have seen over the course of the last cycle are not really related to the configuration of the scheduler by rather races with the scheduler not having a correct picture of the state of the system. Bu that is going on a tangent as it is not related to this proposal.","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c0f698f0d778ccb3f8171df9c4687dcd05a38799","unresolved":false,"context_lines":[{"line_number":62,"context_line":"helpful, such as:"},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"  \"You requested a PCI device, but this deployment is not configured"},{"line_number":65,"context_line":"  for PCI passthrough.\""},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Alternatives"},{"line_number":68,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7aaa499b_e9e3bea2","line":65,"in_reply_to":"7aaa499b_7afe8039","updated":"2015-04-15 17:05:56.000000000","message":"This doesn\u0027t extend to things that are compute node specific. This is mostly scheduler config sanity checking, which can extend to things that are global config, but affect the compute nodes. For example, some thing we\u0027re requesting in our boot that somehow requires neutron can be failed quickly with a check of is_neutron(). Not sure if anything like that exists, but that\u0027s an example.\n\nHowever, the examples here are discoverable just by looking at scheduler config and failing a request that specifies a thing that won\u0027t get checked because a filter isn\u0027t enabled, etc.","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"},{"author":{"_account_id":1063,"name":"Ed Leafe","email":"ed@leafe.com","username":"ed-leafe"},"change_message_id":"252681ae795c6da00a0cd2d75a7e6ac0a019319c","unresolved":false,"context_lines":[{"line_number":70,"context_line":"We could do nothing. This is just an attempt to improve the UX for the"},{"line_number":71,"context_line":"operators and users around scheduling when the request doesn\u0027t make"},{"line_number":72,"context_line":"sense. Improving docs may help people not hit these issues in the"},{"line_number":73,"context_line":"first place, but no amount of improved documentation will prevent it all."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Data model impact"},{"line_number":76,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1af86dd1_aa73cb4c","line":73,"updated":"2015-06-12 15:59:59.000000000","message":"I think a better alternative would be for the API to validate the request via the config options, before it is even passed to the scheduler. Using a filter to do this seems odd, since filters should be acting on valid requests against hosts.","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"},{"author":{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},"change_message_id":"b3c5ff14a70a576a8b05cced522d8664fd596657","unresolved":false,"context_lines":[{"line_number":105,"context_line":"Performance Impact"},{"line_number":106,"context_line":"------------------"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"This will potentially reduce load on the scheduler. By running early"},{"line_number":109,"context_line":"and being mostly static comparisons, we will eliminate ill-fated"},{"line_number":110,"context_line":"requests from running through the rest of the filter stack, and in"},{"line_number":111,"context_line":"some cases, from hitting the compute node before we discover that they"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7aaa499b_5535d5d7","line":108,"updated":"2015-04-14 15:27:04.000000000","message":"If a host fails to spawn the instance then it will be rescheduled - this is where I am not sure how this proposal fits in - the scheduler will need to to know if the compute node can actually deploy the instance - and if you take the example of PCI and NUMA races which we have not sure how this will help.","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c0f698f0d778ccb3f8171df9c4687dcd05a38799","unresolved":false,"context_lines":[{"line_number":105,"context_line":"Performance Impact"},{"line_number":106,"context_line":"------------------"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"This will potentially reduce load on the scheduler. By running early"},{"line_number":109,"context_line":"and being mostly static comparisons, we will eliminate ill-fated"},{"line_number":110,"context_line":"requests from running through the rest of the filter stack, and in"},{"line_number":111,"context_line":"some cases, from hitting the compute node before we discover that they"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7aaa499b_a997f6ea","line":108,"in_reply_to":"7aaa499b_5535d5d7","updated":"2015-04-15 17:05:56.000000000","message":"This isn\u0027t intended to solve world hunger.\n\nHowever, there are a class of issues that are only discoverable after we have sent an impossible request to three compute nodes and seen three failues. If I make a request that specifies a numa topology and that is not supported by any of my compute nodes because I\u0027m using Xen (identifiable by the numa filter not being enabled in the scheduler) then I will consume the resources required to attempt to boot the instance three times before getting the failure. This is load on those compute nodes, load on the scheduler, etc. I should have been able to kick that out immediately as \"not something I can do.\"","commit_id":"82286ab510942003368a9be178ea8d13ed3edf28"}]}