)]}'
{"placement/conf/placement.py":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"9e260b0cce4b91c99240eb5f56a5183f4756b6ef","unresolved":false,"context_lines":[{"line_number":64,"context_line":"\"\"\"),"},{"line_number":65,"context_line":"    cfg.IntOpt("},{"line_number":66,"context_line":"        \u0027allocation_conflict_retry_count\u0027,"},{"line_number":67,"context_line":"        default\u003d10,"},{"line_number":68,"context_line":"        help\u003d\"\"\""},{"line_number":69,"context_line":"The number of times to retry, server-side, writing allocations when there is"},{"line_number":70,"context_line":"a resource provider generation conflict. Raising this value may be useful"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fa7e38b_55428869","line":67,"range":{"start_line":67,"start_character":16,"end_line":67,"end_character":18},"updated":"2019-11-04 14:43:11.000000000","message":"is it worth making a value that means \"infinite\" (None or -1)?","commit_id":"e2599b3af155111e9ddd30f227bfc751b50690df"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"bfc6c08e9fb5f2c7232211f69790593269e6039e","unresolved":false,"context_lines":[{"line_number":64,"context_line":"\"\"\"),"},{"line_number":65,"context_line":"    cfg.IntOpt("},{"line_number":66,"context_line":"        \u0027allocation_conflict_retry_count\u0027,"},{"line_number":67,"context_line":"        default\u003d10,"},{"line_number":68,"context_line":"        help\u003d\"\"\""},{"line_number":69,"context_line":"The number of times to retry, server-side, writing allocations when there is"},{"line_number":70,"context_line":"a resource provider generation conflict. Raising this value may be useful"}],"source_content_type":"text/x-python","patch_set":2,"id":"3fa7e38b_38d6e3c4","line":67,"range":{"start_line":67,"start_character":16,"end_line":67,"end_character":18},"in_reply_to":"3fa7e38b_55428869","updated":"2019-11-04 15:41:30.000000000","message":"No. Things that do not stop are bad.","commit_id":"e2599b3af155111e9ddd30f227bfc751b50690df"}],"releasenotes/notes/allocation_conflict_retry_count-329daae86059f5ec.yaml":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"2c1766d177a1b185848d3f4c33191c4342bb5cd5","unresolved":false,"context_lines":[{"line_number":6,"context_line":"    generation conflict. When those retries are all consumed, the client"},{"line_number":7,"context_line":"    receives an HTTP 409 response and may choose to try the request again."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    If an environment where high levels of concurrent allocation writes are"},{"line_number":10,"context_line":"    common, such as a busy clustered hypervisor or Ironic installation, the"},{"line_number":11,"context_line":"    default retry count may be too low. See story 2006467_"},{"line_number":12,"context_line":""}],"source_content_type":"text/x-yaml","patch_set":1,"id":"7faddb67_92741dd2","line":9,"range":{"start_line":9,"start_character":4,"end_line":9,"end_character":6},"updated":"2019-08-28 20:58:14.000000000","message":"In","commit_id":"63386c0117f7b2faed001ffa1cd17fda405ca0f5"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"06cdd652b6e544cf070769552d2c87f872bd2ab2","unresolved":false,"context_lines":[{"line_number":7,"context_line":"    receives an HTTP 409 response and may choose to try the request again."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    In an environment where high levels of concurrent allocation writes are"},{"line_number":10,"context_line":"    common, such as a busy clustered hypervisor or Ironic installation, the"},{"line_number":11,"context_line":"    default retry count may be too low. See story 2006467_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"    A new configuation setting,"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_21d89cee","line":10,"range":{"start_line":10,"start_character":12,"end_line":10,"end_character":70},"updated":"2019-11-12 13:44:46.000000000","message":"Does this \"busy clustered hypervisor\" mean a big single resource provider? I thought VMware (and Ironic) had only one nova-compute service for N compute-nodes but had N resource providers for N compute nodes.\n\nThat said, I still don\u0027t get why decrease of the clients - nova-compute, the alloc reporters - causes concurrency on one resource provider.","commit_id":"e2599b3af155111e9ddd30f227bfc751b50690df"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"d8b4c09c7e469d59a5fdc3253c8f63d4c92efc7c","unresolved":false,"context_lines":[{"line_number":7,"context_line":"    receives an HTTP 409 response and may choose to try the request again."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    In an environment where high levels of concurrent allocation writes are"},{"line_number":10,"context_line":"    common, such as a busy clustered hypervisor or Ironic installation, the"},{"line_number":11,"context_line":"    default retry count may be too low. See story 2006467_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"    A new configuation setting,"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_5e11ebae","line":10,"range":{"start_line":10,"start_character":12,"end_line":10,"end_character":70},"in_reply_to":"3fa7e38b_0179e0c3","updated":"2019-11-13 00:52:01.000000000","message":"\u003e In a vsphere setup, there is one resource provider for a cluster\n\nOkay, that makes sense and clear things.\n\n \u003e It\u0027s true that in ironic there are many resource providers\n \u003e associated with the one nova-compute process, but this is not the\n \u003e case when using the vmware virt driver.\n\nYes, this was my question. Then why is ironic case mentioned in the release note? Theoritically, the same situation does not happen on ironic where nodes are not combined to a single resource provider, does it? \n\n \u003e [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010669.html\n\nAgreed that this ML discussion [1] is related both to ironic case and to VMware case, because the root cause of this is to have one nova-compute to report all nodes with a lock on client side. But the root cause of story/2006467 seems to be having a big resource provider with big inventory on server side, which sounds to me a bit different with the lock discussion above and not relevant to ironic, I think?","commit_id":"e2599b3af155111e9ddd30f227bfc751b50690df"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"b809e6df11094155b9ac72d994ad5a14dab28181","unresolved":false,"context_lines":[{"line_number":7,"context_line":"    receives an HTTP 409 response and may choose to try the request again."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    In an environment where high levels of concurrent allocation writes are"},{"line_number":10,"context_line":"    common, such as a busy clustered hypervisor or Ironic installation, the"},{"line_number":11,"context_line":"    default retry count may be too low. See story 2006467_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"    A new configuation setting,"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_0179e0c3","line":10,"range":{"start_line":10,"start_character":12,"end_line":10,"end_character":70},"in_reply_to":"3fa7e38b_21d89cee","updated":"2019-11-12 13:55:46.000000000","message":"In a vsphere setup, there is one resource provider for a cluster which could have a very big inventory (1000s of vcpus in some rare cases). In such a setup there is only one nova-compute in the entire openstack installation.\n\nThat means that when there is a request to schedule a workload, it will get one allocation candidate in response, and try to write allocations for it. If nova-scheduler is running currently (which it now does by default) several of these allocations can happen at once, to the same resource provider and each successful one will bump the resource provider generation, increasing the chance of conflict for the others.\n\nIt\u0027s true that in ironic there are many resource providers associated with the one nova-compute process, but this is not the case when using the vmware virt driver. In that setup, all the individual physical hosts in the cluster are considered as one big one.\n\nThis was a design decision made sometime in the past to allow vmware features like DRS (distributed resource scheduler), vMotion (unattended automatic live migration), and other features (High Availability, Fault Tolerance, Admission Control) to work in the fancy way that vmware wants them to.\n\nIt\u0027s been acknowledged time and again that this causes an impedance mismatch with how nova wants to think about hypervisors (see [1] for a recent discussion) but efforts to do things differently have foundered and floundered.\n\n\n[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010669.html","commit_id":"e2599b3af155111e9ddd30f227bfc751b50690df"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"12b964e550154b9c804ff1062eea25b1434b6186","unresolved":false,"context_lines":[{"line_number":7,"context_line":"    receives an HTTP 409 response and may choose to try the request again."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    In an environment where high levels of concurrent allocation writes are"},{"line_number":10,"context_line":"    common, such as a busy clustered hypervisor or Ironic installation, the"},{"line_number":11,"context_line":"    default retry count may be too low. See story 2006467_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"    A new configuation setting,"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_93c2f433","line":10,"range":{"start_line":10,"start_character":12,"end_line":10,"end_character":70},"in_reply_to":"3fa7e38b_5e11ebae","updated":"2019-11-13 12:12:20.000000000","message":"\u003e \n \u003e Yes, this was my question. Then why is ironic case mentioned in the\n \u003e release note? Theoritically, the same situation does not happen on\n \u003e ironic where nodes are not combined to a single resource provider,\n \u003e does it?\n \nGood point, I\u0027ll make the note more specific.","commit_id":"e2599b3af155111e9ddd30f227bfc751b50690df"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"7d2dcf4c16a3dde952797f5512e4920ece51f91b","unresolved":false,"context_lines":[{"line_number":7,"context_line":"    receives an HTTP 409 response and may choose to try the request again."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"    In an environment where high levels of concurrent allocation writes are"},{"line_number":10,"context_line":"    common, such as a busy clustered hypervisor or Ironic installation, the"},{"line_number":11,"context_line":"    default retry count may be too low. See story 2006467_"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"    A new configuation setting,"}],"source_content_type":"text/x-yaml","patch_set":2,"id":"3fa7e38b_62d3cc02","line":10,"range":{"start_line":10,"start_character":12,"end_line":10,"end_character":70},"in_reply_to":"3fa7e38b_93c2f433","updated":"2019-11-14 15:47:26.000000000","message":"It looks like you made the note more general :P","commit_id":"e2599b3af155111e9ddd30f227bfc751b50690df"}]}