)]}'
{"doc/source/specs/train/approved/2005575-nested-magic.rst":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0b286097fde79c21b1f2ae540e0432db3a037bbe","unresolved":false,"context_lines":[{"line_number":14,"context_line":"interrelated use cases for Train around:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":"* Still being able to satisfy existing (\"simple\") use cases against complex"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dfbec78f_6d52883d","line":17,"range":{"start_line":17,"start_character":13,"end_line":17,"end_character":21},"updated":"2019-05-15 16:51:09.000000000","message":"It\u0027s probably worth defining this term, in this context, so as to avoid confusion. I know that I tend to slide between multiple connotations.","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a16bd0e76469bc87cf2d3088fd3d9ce1bc23face","unresolved":false,"context_lines":[{"line_number":14,"context_line":"interrelated use cases for Train around:"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"* Modeling complex trees such as NUMA layouts, multiple devices, networks."},{"line_number":17,"context_line":"* Requesting affinity between/among the various providers/allocations in"},{"line_number":18,"context_line":"  allocation candidates against such layouts."},{"line_number":19,"context_line":"* Describing granular groups more richly to facilitate the above."},{"line_number":20,"context_line":"* Still being able to satisfy existing (\"simple\") use cases against complex"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_3822e301","line":17,"range":{"start_line":17,"start_character":13,"end_line":17,"end_character":21},"in_reply_to":"dfbec78f_6d52883d","updated":"2019-05-23 22:37:06.000000000","message":"I think the use case for same_subtree clarifies. I\u0027ll link from here to there, cool?","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0b286097fde79c21b1f2ae540e0432db3a037bbe","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Data model impact"},{"line_number":37,"context_line":"-----------------"},{"line_number":38,"context_line":"None. All of these changes should be above the database layer."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"API impact"},{"line_number":41,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dfbec78f_edaf5827","line":38,"updated":"2019-05-15 16:51:09.000000000","message":"I agree that the data model will not be impacted, but certainly the code that interacts with the database will be. I\u0027m undecided whether that is the database layer. Even if not, the changes that need to happen at that layer should get some small measure of attention in this spec, even if just to say \"this will likely cause plenty of adjustment in the objects/*.py files\".","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a16bd0e76469bc87cf2d3088fd3d9ce1bc23face","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Data model impact"},{"line_number":37,"context_line":"-----------------"},{"line_number":38,"context_line":"None. All of these changes should be above the database layer."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"API impact"},{"line_number":41,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_b85c937e","line":38,"in_reply_to":"dfbec78f_edaf5827","updated":"2019-05-23 22:37:06.000000000","message":"I\u0027ll wordsmith something.","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0b286097fde79c21b1f2ae540e0432db3a037bbe","unresolved":false,"context_lines":[{"line_number":75,"context_line":"~~~~~~~~~"},{"line_number":76,"context_line":"**Use case:** My cloud includes hosts modeled with NUMA layouts, such that"},{"line_number":77,"context_line":"inventories of ``VCPU`` and ``MEMORY_MB`` are divided among multiple resource"},{"line_number":78,"context_line":"providers. I want to be able to design flavors for instances that *don\u0027t care"},{"line_number":79,"context_line":"about NUMA affinity* but can still land on such hosts. Further, I want to"},{"line_number":80,"context_line":"maximize the probability that the instance can still land on a host where the"},{"line_number":81,"context_line":"required amount of a given resource is only satisfied when available"},{"line_number":82,"context_line":"inventories of multiple providers are considered in sum."}],"source_content_type":"text/x-rst","patch_set":2,"id":"dfbec78f_c0a57ba3","line":79,"range":{"start_line":78,"start_character":11,"end_line":79,"end_character":54},"updated":"2019-05-15 16:51:09.000000000","message":"If the driving use case is \"don\u0027t care about...\" and the unspecified request group can be satisfied by any provider, is there a chance here that we can get away without a suffix on can_split and still manage to satisfy the main goal.\n\nI was inspired to ask this by your sentence starting \"Granular requests groups usually...\" below.\n\nI know we talked about this some during the period that created the images that are on https://storyboard.openstack.org/#!/story/2005575 but given the rather expanding nature of this feature, I\u0027m wondering if we can get some 80/20 by easing into it?\n\nI\u0027m not saying we should, just asking if it is an option. See more in this vein below.","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"da3d81167db1a3106973849270180bac48780e17","unresolved":false,"context_lines":[{"line_number":131,"context_line":"  1280      0"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"**Candidate Explosion**"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There is concern that ``can_split$S`` on resource classes whose inventories"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dfbec78f_b8d3f35f","line":134,"updated":"2019-05-14 19:38:31.000000000","message":"Given the above model, what is the behavior of:\n\n resources_FOO\u003dVCPU:4,MEMORY_MB:1280\u0026can_split_FOO\u003dVCPU,MEMORY_MB\n\nGranular group rules usually dictate that resources come from the same provider; so does the above still yield results like:\n\n - numa0: {MEMORY_MB:1280}, numa1: {VCPU:4}\n\ni.e. all the memory comes from one provider and all the VCPU comes from the other?\n\nI\u0027ll say yes. To me, can_split_FOO\u003dVCPU,MEMORY_MB intuitively means \"Go ahead and get the VCPU and MEMORY_MB from different providers as needed.\" And also, to do otherwise would probably be uglier code, because I suspect we would need to artificially strip out candidates that \"break\" this hard-to-express rule.\n\nSo then what about:\n\n resources_FOO\u003dVCPU:4,MEMORY_MB:1280\u0026can_split_FOO\u003dVCPU\n\nThis should clearly return candidates:\n\n - numa0: {MEMORY_MB:1280, VCPU:1}, numa1: {VCPU:3}\n - numa0: {MEMORY_MB:1280, VCPU:2}, numa1: {VCPU:2}\n\nbut should it also return:\n\n - numa0: {MEMORY_MB:1280}, numa1: {VCPU:4}\n\nconsidering I *didn\u0027t* say you could \"split\" MEMORY_MB?\n\nAgain yes, and here\u0027s why: what we really want this syntax for is to make sure a request including DISK_GB can land on a flat *or* NUMA-modeled host. So extending the model to:\n\n                 +--------------+\n                 | compute node |\n                 | DISK_GB: 200 |\n                 +------+-------+\n                        |\n              +---------+----------+\n              |                    |\n    +---------+--------+ +---------+--------+\n    | numa0            | | numa1            |\n    | VCPU: 4 (2 used) | | VCPU: 4          |\n    | MEMORY_MB: 2048  | | MEMORY_MB: 2048  |\n    |   min_unit: 512  | |   min_unit: 256  |\n    |   step_size: 256 | |   max_unit: 1024 |\n    +------------------+ +------------------+\n\n...my \"land anywhere\" request could be:\n\n resources_FOO\u003dVCPU:4\u0026MEMORY_MB:1280\u0026DISK_GB:50\u0026can_split_FOO\u003dVCPU,MEMORY_MB\n\n...and it would be disastrous if we *excluded* results where DISK_GB was the only resource on its provider - because that would be all of them.\n\n(Note that using the unspecified group for the above request would make the point moot, but go with me for a minute...)\n\nBy extension, I think that actually defines \"can_split$S\" as:\n\n- Resources in group $S which are of different classes are always allowed to come from different providers - i.e. by saying can_split$S at all you\u0027re making group $S behave like the unspecified group in this regard.\n- Resources whose classes are listed in the value of can_split$S may be further subdivided among different providers.\n\nWhich leads into a couple of interesting corners:\n\n- Is it legal to say can_split_FOO\u003d (empty value), thereby *only* making group _FOO behave like the unspecified group?\n- If so, we could actually get rid of the unspecified group entirely - i.e. *require* a suffix and make all groups subject to the same rules and behavior. This would make a number of things cleaner and easier to deal with, including keying the rg-to-rp \"mappings\" dict [1].\n\n\u003d\u003d\u003d\u003d\u003d\n\nThere are parts of this that make me uncomfortable. Once we get into the corner cases (but not until then, IMO), it feels like we\u0027re overloading can_split to mean two things. And allowing a key with an empty value to have semantic significance also feels weird. But I\u0027m not sure if there\u0027s a cleaner answer, and I\u0027m too burned out to think more about it right now.\n\n[1] https://review.opendev.org/#/c/657582/1/doc/source/specs/train/approved/placement-resource-provider-request-group-mapping-in-allocation-candidates.rst@357","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0b286097fde79c21b1f2ae540e0432db3a037bbe","unresolved":false,"context_lines":[{"line_number":131,"context_line":"  1280      0"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"**Candidate Explosion**"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There is concern that ``can_split$S`` on resource classes whose inventories"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dfbec78f_e0743fd1","line":134,"in_reply_to":"dfbec78f_b8d3f35f","updated":"2019-05-15 16:51:09.000000000","message":"\u003e - Resources in group $S which are of different classes are always\n \u003e allowed to come from different providers - i.e. by saying\n \u003e can_split$S at all you\u0027re making group $S behave like the\n \u003e unspecified group in this regard.\n\nIf some resources are always allowed to come from different providers, why have them associated with a group at all? It seems to remove the idea of the group. The second half of your statement says pretty much the same thing.\n\nSo: what use case requires can_split to have a suffix? Is it so we have subtree affinity + can_split in the same go (some mention of it below at \"**same_subtree + can_split**\")? Is that a thing it is important to enable?\n\n \u003e - If so, we could actually get rid of the unspecified group\n \u003e entirely - i.e. *require* a suffix and make all groups subject to\n \u003e the same rules and behavior. This would make a number of things\n \u003e cleaner and easier to deal with, including keying the rg-to-rp\n \u003e \"mappings\" dict [1].\n\nIf you\u0027re saying \"resources, required, etc\" always require a suffix (are you?) I don\u0027t think it would be a good idea to go down that path because:\n\n* it\u0027s a shift in grammar which, even with microversions, is abrupt\n* it\u0027s requiring an edge (both definitions) case syntax for what we\u0027d (I?) like to define as the golden happy common path that is free of extraneous goo: `GET /allocation_candidates?resources\u003dVCPU:1,MEMORY_MB:256,DISK_GB:1` ought to be dime a dozen\n\nIf the answer to my first question in my previous block of comment is \"yes\" maybe we can trim some mess here.\n\n(On the empty string as key on the mappings dict, that doesn\u0027t bother me much. Both Python and Javascript/JSON are happy with \u0027\u0027 as a key. There are other complexities, but I don\u0027t think we need to worry overmuch about that one.)","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a16bd0e76469bc87cf2d3088fd3d9ce1bc23face","unresolved":false,"context_lines":[{"line_number":131,"context_line":"  1280      0"},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"**Candidate Explosion**"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"There is concern that ``can_split$S`` on resource classes whose inventories"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_2dfe2737","line":134,"in_reply_to":"dfbec78f_e0743fd1","updated":"2019-05-23 22:37:06.000000000","message":"Thanks as always for challenging me to KISS.\n\nWhile I can contrive use cases for can_split$S, I agree that none are compelling or immediate, and the pitfalls almost certainly outweigh the benefits.\n\nI will revise with only unsuffixed can_split.","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0b286097fde79c21b1f2ae540e0432db3a037bbe","unresolved":false,"context_lines":[{"line_number":150,"context_line":"aggregate with the tree? Intuitively, it seems like the sharing provider should"},{"line_number":151,"context_line":"be treated just like any other for purposes of ``can_split$S``. Is that doable?"},{"line_number":152,"context_line":"Would we have a way to make it otherwise (block it somehow) if we decided that"},{"line_number":153,"context_line":"was just too crazy?"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"same_subtree"},{"line_number":156,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dfbec78f_230b4124","line":153,"updated":"2019-05-15 16:51:09.000000000","message":"This is an excellent question to ask, but my preference would be that can_split be constrained to not include sharing providers if possible.\n\nAt least at first glance it is hard to imagine a situation where you would want to split to (or among) sharing provider(s) and didn\u0027t want to make that explicit in the request (multiple blocks of contiguous disk of different sizes). vmware and powervm hypervisor models might throw a wrench in that, but if we can incremental that might be the best way here.","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7b8af71cd2f119b05262226a328095f82fe0422d","unresolved":false,"context_lines":[{"line_number":150,"context_line":"aggregate with the tree? Intuitively, it seems like the sharing provider should"},{"line_number":151,"context_line":"be treated just like any other for purposes of ``can_split$S``. Is that doable?"},{"line_number":152,"context_line":"Would we have a way to make it otherwise (block it somehow) if we decided that"},{"line_number":153,"context_line":"was just too crazy?"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"same_subtree"},{"line_number":156,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_92115c55","line":153,"in_reply_to":"bfb3d3c7_58c5575a","updated":"2019-05-24 12:09:08.000000000","message":"I try.\n\nWe currently model the bandwidth on the device closes to the nova server, which is the physical nic (or integration bridge) on the compute host. \n\nBut bandwidth as a consumable exists further in the network as well. The next step would be to model the bandwidth on the TOR switch. As a TOR switch connect a set of compute hosts the bandwidth resource on the TOR switch is shared between such compute hosts. So TOR switch can be modeled with a sharing RP. \n\nNow imagine that you have a nova server with an neutron port that is realized by (plugged into) some kind of bonded interface on the compute host. The two legs of the bond could be connected to two separate TOR switches. If we need to model the consumed TOR switch bandwidth resource in this case then that bandwidth might be split between two sharing bandwidth providers representing the two separate TOR switches.\n\n// There is a really long way to realize the support for the above setup. We need to handle bonding, we need to model TOR switches, we need to model bandwidth on the TOR...","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"c2e7a8102c0e8fbd928eedab326572029799e612","unresolved":false,"context_lines":[{"line_number":150,"context_line":"aggregate with the tree? Intuitively, it seems like the sharing provider should"},{"line_number":151,"context_line":"be treated just like any other for purposes of ``can_split$S``. Is that doable?"},{"line_number":152,"context_line":"Would we have a way to make it otherwise (block it somehow) if we decided that"},{"line_number":153,"context_line":"was just too crazy?"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"same_subtree"},{"line_number":156,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_29536241","line":153,"in_reply_to":"bfb3d3c7_92115c55","updated":"2019-05-24 20:17:44.000000000","message":"Yeah, in other words, we can\u0027t do it within the scope of what we\u0027ve got planned for Train anyway; so there\u0027s no reason for us to go to the effort to support it yet.\n\n(I think this is what you\u0027ve agreed to in PS4, please correct me if I\u0027m wrong.)","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a16bd0e76469bc87cf2d3088fd3d9ce1bc23face","unresolved":false,"context_lines":[{"line_number":150,"context_line":"aggregate with the tree? Intuitively, it seems like the sharing provider should"},{"line_number":151,"context_line":"be treated just like any other for purposes of ``can_split$S``. Is that doable?"},{"line_number":152,"context_line":"Would we have a way to make it otherwise (block it somehow) if we decided that"},{"line_number":153,"context_line":"was just too crazy?"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"same_subtree"},{"line_number":156,"context_line":"~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_58c5575a","line":153,"in_reply_to":"dfbec78f_230b4124","updated":"2019-05-23 22:37:06.000000000","message":"Certainly DISK_GB, which is the leading case for sharing, doesn\u0027t make sense to can_split. If I want two disks, I care what size they are, and I use two groups. If it\u0027s okay that they come from the same provider (sharing or otherwise), I use group_policy\u003dnone.\n\nI vaguely remember other sharing use cases involving network switches or something - gibi, can you come up with an example where it would be important (and unavoidable) to can_split on a sharing provider?\n\nFor now I\u0027ll revise assuming we can\u0027t split on a sharing provider.\n\n(Note that it\u0027s possible that restricting can_split + sharing providers will actually be *more* code. However, given the test surface, the net will probably be smaller overall.)","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0b286097fde79c21b1f2ae540e0432db3a037bbe","unresolved":false,"context_lines":[{"line_number":360,"context_line":"   \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":361,"context_line":"   \u0026required_AFFINITY\u003dHW_NUMA_ROOT"},{"line_number":362,"context_line":"   \u0026can_split_VIF\u003dVF"},{"line_number":363,"context_line":"   \u0026same_subtree\u003d_VIF,_ACCEL,_AFFINITY"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"  will return candidates including::"},{"line_number":366,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dfbec78f_e33c4930","line":363,"updated":"2019-05-15 16:51:09.000000000","message":"Can we get same/similar results by replacing can_split with group_policy\u003disolate ? Are there other options to get a reasonable result set (using more group?)?\n\nI ask because of my queries above. However, if can_split$S is the best way to get a result set like this, I guess that gives us a use case...","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a16bd0e76469bc87cf2d3088fd3d9ce1bc23face","unresolved":false,"context_lines":[{"line_number":360,"context_line":"   \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":361,"context_line":"   \u0026required_AFFINITY\u003dHW_NUMA_ROOT"},{"line_number":362,"context_line":"   \u0026can_split_VIF\u003dVF"},{"line_number":363,"context_line":"   \u0026same_subtree\u003d_VIF,_ACCEL,_AFFINITY"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"  will return candidates including::"},{"line_number":366,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_18183fd1","line":363,"in_reply_to":"dfbec78f_e33c4930","updated":"2019-05-23 22:37:06.000000000","message":"There\u0027s absolutely another way to do this:\n\n ?resources_VIF1\u003dVF:1\n \u0026resources_VIF2\u003dVF:1\n \u0026resources_ACCEL\u003dFPGA:1\n \u0026required_AFFINITY\u003dHW_NUMA_ROOT\n \u0026same_subtree\u003d_VIF,_ACCEL,_AFFINITY\n \u0026group_policy\u003dnone\n\nThe whole\n\n ?resources1\u003d$RC:1\n \u0026resources2\u003d$RC:1\n \u0026...\n \u0026resourcesN\u003d$RC:1\n \u0026group_policy\u003dnone\n\nthing is why we needed can_split in the first place. We didn\u0027t want to have to translate a flavor request of vcpu\u003d16 into 16 request groups of 1 VCPU each. We also couldn\u0027t answer same for more contiguous-y resource classes like MEMORY_MB.\n\nBut I think it\u0027s fair to say - for now, anyway - that\n- the only contiguous-y resource class we need to worry about in nested providers is MEMORY_MB (requests for bandwidth already go into separate groups and we don\u0027t want to split them)\n- if you\u0027re wanting to split VCPU and/or MEMORY_MB, you\u0027re using the unsuffixed group for them; and\n- the quantities of any other resources we\u0027re dealing with in nested providers will be small (you ain\u0027t gonna want 16 VFs (are you??)).\n\nSo as noted above, I\u0027m good with eliminating can_split$S for now.","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"0b286097fde79c21b1f2ae540e0432db3a037bbe","unresolved":false,"context_lines":[{"line_number":383,"context_line":""},{"line_number":384,"context_line":"Performance Impact"},{"line_number":385,"context_line":"------------------"},{"line_number":386,"context_line":"Oh yes."},{"line_number":387,"context_line":""},{"line_number":388,"context_line":"Other deployer impact"},{"line_number":389,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dfbec78f_0382bdc8","line":386,"updated":"2019-05-15 16:51:09.000000000","message":"Quite.\n\nHowever, maybe this process will reveal some areas ripe for tuneup.","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"a16bd0e76469bc87cf2d3088fd3d9ce1bc23face","unresolved":false,"context_lines":[{"line_number":383,"context_line":""},{"line_number":384,"context_line":"Performance Impact"},{"line_number":385,"context_line":"------------------"},{"line_number":386,"context_line":"Oh yes."},{"line_number":387,"context_line":""},{"line_number":388,"context_line":"Other deployer impact"},{"line_number":389,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfb3d3c7_d81147ae","line":386,"in_reply_to":"dfbec78f_0382bdc8","updated":"2019-05-23 22:37:06.000000000","message":"Sure.\n\nI\u0027m thinking mainly of the explosion can_split is going to cause...","commit_id":"ce4119b11d18b641906d0fca13dc8a37cf6c7c45"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","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\u003d"},{"line_number":8,"context_line":"Getting On The Nested Magic Train"},{"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\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://storyboard.openstack.org/#!/story/2005575"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_3233d0f8","line":8,"range":{"start_line":8,"start_character":28,"end_line":8,"end_character":33},"updated":"2019-05-24 13:42:04.000000000","message":"Denver forever!","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","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\u003d"},{"line_number":8,"context_line":"Getting On The Nested Magic Train"},{"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\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://storyboard.openstack.org/#!/story/2005575"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_c070370b","line":8,"range":{"start_line":8,"start_character":28,"end_line":8,"end_character":33},"in_reply_to":"bfb3d3c7_3233d0f8","updated":"2019-05-28 17:28:21.000000000","message":"this is such a terrible dad joke ...\nits perfect :)","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Proposed change"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"All changes are to the ``GET /allocation_candidates`` operation via new"},{"line_number":31,"context_line":"microversions, one per feature described below."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"arbitrary group suffixes"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_20e7d3ae","line":30,"range":{"start_line":30,"start_character":23,"end_line":30,"end_character":53},"updated":"2019-05-28 17:28:21.000000000","message":"do we have any need to support the same feature on the resource provider endpoint or just the allocation candidates endpoint","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"5ab7191c2c19cf9caad21320039f6a87587f70f1","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Proposed change"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"All changes are to the ``GET /allocation_candidates`` operation via new"},{"line_number":31,"context_line":"microversions, one per feature described below."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"arbitrary group suffixes"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_83ea38d5","line":30,"range":{"start_line":30,"start_character":23,"end_line":30,"end_character":53},"in_reply_to":"bfb3d3c7_20e7d3ae","updated":"2019-05-29 11:03:07.000000000","message":"/resource_providers doesn\u0027t have any conception of filtering or representing results in terms of their nested topology, so no \u0027granular\u0027.\n\nSo, short answer: no","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9b0b29070c6515c10bea0686087c2c6a414cf6af","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Proposed change"},{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"All changes are to the ``GET /allocation_candidates`` operation via new"},{"line_number":31,"context_line":"microversions, one per feature described below."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"arbitrary group suffixes"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_66063223","line":30,"range":{"start_line":30,"start_character":23,"end_line":30,"end_character":53},"in_reply_to":"bfb3d3c7_83ea38d5","updated":"2019-05-29 13:04:38.000000000","message":"cool that works for me.\nwe have parity for some things between both endpoint so just wanted to make sure this was not one of them.\nif we dong currently support granular for /resouce_providers\nthen we certenly don\u0027t need these enhancements.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":28,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"All changes are to the ``GET /allocation_candidates`` operation via new"},{"line_number":31,"context_line":"microversions, one per feature described below."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"arbitrary group suffixes"},{"line_number":34,"context_line":"------------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_d2591435","line":31,"range":{"start_line":31,"start_character":15,"end_line":31,"end_character":47},"updated":"2019-05-24 13:42:04.000000000","message":"+1","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":45,"context_line":"Code is here: https://review.opendev.org/#/c/657419/"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Granular groups are currently restricted to using integer suffixes. We will"},{"line_number":48,"context_line":"change this so they can be up to 64c comprising alphanumeric (either case),"},{"line_number":49,"context_line":"underscore, and hyphen."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_00b08f89","line":48,"range":{"start_line":48,"start_character":33,"end_line":48,"end_character":36},"updated":"2019-05-28 17:28:21.000000000","message":"is assume you mean 64 characters.\nare retresticing these to to the latin set\n[a-zA-Z0-9_\\-]? ascii? or utf8?\n\ni think [a-zA-Z0-9_\\-]","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"85aa65dde182604b6049584f1ac183c7b069ba65","unresolved":false,"context_lines":[{"line_number":45,"context_line":"Code is here: https://review.opendev.org/#/c/657419/"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"Granular groups are currently restricted to using integer suffixes. We will"},{"line_number":48,"context_line":"change this so they can be up to 64c comprising alphanumeric (either case),"},{"line_number":49,"context_line":"underscore, and hyphen."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_ada2d4ac","line":48,"range":{"start_line":48,"start_character":33,"end_line":48,"end_character":36},"in_reply_to":"bfb3d3c7_00b08f89","updated":"2019-05-29 20:10:17.000000000","message":"Yes, see code linked above, which is now merged (microversion 1.33).","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"},{"line_number":52,"context_line":"  designation. Like ``resources_PORT_$UUID``."},{"line_number":53,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":54,"context_line":"* Uppercase so consumers can make nice visual distinctions like"},{"line_number":55,"context_line":"  ``resources_PORT...``; lowercase because openstack consumers tend to use"},{"line_number":56,"context_line":"  lowercase UUIDs and this makes them not have to convert them."},{"line_number":57,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":58,"context_line":"* **Alternative** Uppercase only so we don\u0027t have to worry about case"},{"line_number":59,"context_line":"  sensitivity or confusing differentiation from the prefixes (which are"},{"line_number":60,"context_line":"  lowercase). **Rejected** because we prefer allowing lowercase UUIDs, and are"},{"line_number":61,"context_line":"  willing to give the consumer the rope."},{"line_number":62,"context_line":"  https://review.opendev.org/#/c/657419/1/placement/lib.py@31"},{"line_number":63,"context_line":"* Hyphens so we can use UUIDs without too much scrubbing."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_66116452","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":61},"updated":"2019-05-28 17:28:21.000000000","message":"i would prefer if we ignored case and lowercased everything internally\n\ni really think resources_PORT_$UUID dones not help readablity\ne.g.\nresources_PORT_75a4d210-66a4-4eda-8275-d01fcb2889ac\n\ni think is less readable then either of \n\nresources_port_75a4d210-66a4-4eda-8275-d01fcb2889ac\n\nor \n\nRESOURCES_PORT_75A4D210-66A4-4EDA-8275-D01FCB2889AC\n\ni find\nresources_PORT_75a4d210-66a4-4eda-8275-d01fcb2889ac\n\nvisually quite noisy and precise reading it to take\nmuch more concentration then  either all lower case or all upper","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9b0b29070c6515c10bea0686087c2c6a414cf6af","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"},{"line_number":52,"context_line":"  designation. Like ``resources_PORT_$UUID``."},{"line_number":53,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":54,"context_line":"* Uppercase so consumers can make nice visual distinctions like"},{"line_number":55,"context_line":"  ``resources_PORT...``; lowercase because openstack consumers tend to use"},{"line_number":56,"context_line":"  lowercase UUIDs and this makes them not have to convert them."},{"line_number":57,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":58,"context_line":"* **Alternative** Uppercase only so we don\u0027t have to worry about case"},{"line_number":59,"context_line":"  sensitivity or confusing differentiation from the prefixes (which are"},{"line_number":60,"context_line":"  lowercase). **Rejected** because we prefer allowing lowercase UUIDs, and are"},{"line_number":61,"context_line":"  willing to give the consumer the rope."},{"line_number":62,"context_line":"  https://review.opendev.org/#/c/657419/1/placement/lib.py@31"},{"line_number":63,"context_line":"* Hyphens so we can use UUIDs without too much scrubbing."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_261d9a73","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":61},"in_reply_to":"bfb3d3c7_03b888e2","updated":"2019-05-29 13:04:38.000000000","message":"ok so to be clear are we going to just use the value as given.\n\nupsercase so... follow by lowercase so...\nin the same sentence is is confusing as im not sure if we are saying you must use mixed case which at least for me in the example give i find harder to read the just all lowercase/snake_case.\n\nif we say case matters and we will just use and return what the client gave us then i guess its up to them but\nif find it hard to read resouces and so some degree the start of the uuid when written as resources_PORT_75a4d210-66a... vs\nresources_port_75a4d210-66a\n\nthis does not bother me too much as i likely wont be looking at this frequently but could we clarify this in the next version.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"85aa65dde182604b6049584f1ac183c7b069ba65","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"},{"line_number":52,"context_line":"  designation. Like ``resources_PORT_$UUID``."},{"line_number":53,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":54,"context_line":"* Uppercase so consumers can make nice visual distinctions like"},{"line_number":55,"context_line":"  ``resources_PORT...``; lowercase because openstack consumers tend to use"},{"line_number":56,"context_line":"  lowercase UUIDs and this makes them not have to convert them."},{"line_number":57,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":58,"context_line":"* **Alternative** Uppercase only so we don\u0027t have to worry about case"},{"line_number":59,"context_line":"  sensitivity or confusing differentiation from the prefixes (which are"},{"line_number":60,"context_line":"  lowercase). **Rejected** because we prefer allowing lowercase UUIDs, and are"},{"line_number":61,"context_line":"  willing to give the consumer the rope."},{"line_number":62,"context_line":"  https://review.opendev.org/#/c/657419/1/placement/lib.py@31"},{"line_number":63,"context_line":"* Hyphens so we can use UUIDs without too much scrubbing."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_facf1126","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":61},"in_reply_to":"bfb3d3c7_261d9a73","updated":"2019-05-29 20:10:17.000000000","message":"Okay, the terseness of the wording is confusing, can fix to \"We want to allow uppercase so ...; and we want to allow lowercase so ...\"\n\nAnd it should be explicitly stated that the suffixes are case-sensitive.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"5ab7191c2c19cf9caad21320039f6a87587f70f1","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"},{"line_number":52,"context_line":"  designation. Like ``resources_PORT_$UUID``."},{"line_number":53,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":54,"context_line":"* Uppercase so consumers can make nice visual distinctions like"},{"line_number":55,"context_line":"  ``resources_PORT...``; lowercase because openstack consumers tend to use"},{"line_number":56,"context_line":"  lowercase UUIDs and this makes them not have to convert them."},{"line_number":57,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":58,"context_line":"* **Alternative** Uppercase only so we don\u0027t have to worry about case"},{"line_number":59,"context_line":"  sensitivity or confusing differentiation from the prefixes (which are"},{"line_number":60,"context_line":"  lowercase). **Rejected** because we prefer allowing lowercase UUIDs, and are"},{"line_number":61,"context_line":"  willing to give the consumer the rope."},{"line_number":62,"context_line":"  https://review.opendev.org/#/c/657419/1/placement/lib.py@31"},{"line_number":63,"context_line":"* Hyphens so we can use UUIDs without too much scrubbing."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_03b888e2","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":61},"in_reply_to":"bfb3d3c7_66116452","updated":"2019-05-29 11:03:07.000000000","message":"\u003e i would prefer if we ignored case and lowercased everything\n \u003e internally\n\nWe\u0027ve chosen not to do so as it requires the client to translate to whatever _their_ representation is. If there\u0027s no translation on the placement side, then neither side needs to.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"95a078fafbdceaa5b31766d7938f3e0b79c6bb9f","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"},{"line_number":52,"context_line":"  designation. Like ``resources_PORT_$UUID``."},{"line_number":53,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":54,"context_line":"* Uppercase so consumers can make nice visual distinctions like"},{"line_number":55,"context_line":"  ``resources_PORT...``; lowercase because openstack consumers tend to use"},{"line_number":56,"context_line":"  lowercase UUIDs and this makes them not have to convert them."},{"line_number":57,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":58,"context_line":"* **Alternative** Uppercase only so we don\u0027t have to worry about case"},{"line_number":59,"context_line":"  sensitivity or confusing differentiation from the prefixes (which are"},{"line_number":60,"context_line":"  lowercase). **Rejected** because we prefer allowing lowercase UUIDs, and are"},{"line_number":61,"context_line":"  willing to give the consumer the rope."},{"line_number":62,"context_line":"  https://review.opendev.org/#/c/657419/1/placement/lib.py@31"},{"line_number":63,"context_line":"* Hyphens so we can use UUIDs without too much scrubbing."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_d11c5279","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":61},"in_reply_to":"bfb3d3c7_bc25040b","updated":"2019-05-30 22:38:26.000000000","message":"Chris addressed this in https://review.opendev.org/#/c/662191/","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df23f11f1efbdf9411ca9f1c2ed8b84754041820","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* 64c so we can fit a UUID (with hyphens) as well as some kind of handy type"},{"line_number":52,"context_line":"  designation. Like ``resources_PORT_$UUID``."},{"line_number":53,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":54,"context_line":"* Uppercase so consumers can make nice visual distinctions like"},{"line_number":55,"context_line":"  ``resources_PORT...``; lowercase because openstack consumers tend to use"},{"line_number":56,"context_line":"  lowercase UUIDs and this makes them not have to convert them."},{"line_number":57,"context_line":"  https://review.opendev.org/#/c/657419/4/placement/schemas/allocation_candidate.py@19"},{"line_number":58,"context_line":"* **Alternative** Uppercase only so we don\u0027t have to worry about case"},{"line_number":59,"context_line":"  sensitivity or confusing differentiation from the prefixes (which are"},{"line_number":60,"context_line":"  lowercase). **Rejected** because we prefer allowing lowercase UUIDs, and are"},{"line_number":61,"context_line":"  willing to give the consumer the rope."},{"line_number":62,"context_line":"  https://review.opendev.org/#/c/657419/1/placement/lib.py@31"},{"line_number":63,"context_line":"* Hyphens so we can use UUIDs without too much scrubbing."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_bc25040b","line":62,"range":{"start_line":54,"start_character":0,"end_line":62,"end_character":61},"in_reply_to":"bfb3d3c7_facf1126","updated":"2019-05-30 13:07:35.000000000","message":"cool that works for me +1","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"4f91f5fb11ace50c81ccce03a05bc8f2a0b6c4ce","unresolved":false,"context_lines":[{"line_number":63,"context_line":"* Hyphens so we can use UUIDs without too much scrubbing."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""},{"line_number":66,"context_line":"group to \"unspecified\" or \"unsuffixed\", and anywhere we reference \"numbered\""},{"line_number":67,"context_line":"groups we can call them \"suffixed\" or \"granular\" (I think this label is already"},{"line_number":68,"context_line":"used in some places)."},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_b061ee07","line":66,"updated":"2019-05-25 09:32:52.000000000","message":"Either\n\na) \"suffixed\" group vs. \"unsuffixed\" group\n\nOR\n\nb) \"non-granular\" group vs. \"granular\" group\n\nis my preference","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":63,"context_line":"* Hyphens so we can use UUIDs without too much scrubbing."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""},{"line_number":66,"context_line":"group to \"unspecified\" or \"unsuffixed\", and anywhere we reference \"numbered\""},{"line_number":67,"context_line":"groups we can call them \"suffixed\" or \"granular\" (I think this label is already"},{"line_number":68,"context_line":"used in some places)."},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_a6a75c0b","line":66,"in_reply_to":"bfb3d3c7_b061ee07","updated":"2019-05-28 17:28:21.000000000","message":"i woudl prefer b\nanother otion would be \n\nnamed and unnamed groups \n\nbut i like b.\n\nsuffix feels wrong for reason that are not relevant","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":65,"context_line":"For purposes of documentation (and this spec), we\u0027ll rename the \"unnumbered\""},{"line_number":66,"context_line":"group to \"unspecified\" or \"unsuffixed\", and anywhere we reference \"numbered\""},{"line_number":67,"context_line":"groups we can call them \"suffixed\" or \"granular\" (I think this label is already"},{"line_number":68,"context_line":"used in some places)."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"can_split"},{"line_number":71,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_127d6c7e","line":68,"updated":"2019-05-24 13:42:04.000000000","message":"Such terminology cleanup needs to be done in nova too. :/\n\ngit/nova$ git grep numbered | wc -l\n47","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"3235fc5c49a86e73743b6858738d0400e2523466","unresolved":false,"context_lines":[{"line_number":67,"context_line":"groups we can call them \"suffixed\" or \"granular\" (I think this label is already"},{"line_number":68,"context_line":"used in some places)."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"can_split"},{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":"**Use case:** My cloud includes hosts modeled with NUMA layouts, such that"},{"line_number":73,"context_line":"inventories of ``VCPU`` and ``MEMORY_MB`` are divided among multiple resource"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2a65911e","line":70,"range":{"start_line":70,"start_character":0,"end_line":70,"end_character":9},"updated":"2019-05-24 22:43:34.000000000","message":"I updated the can_split gabbit [1] to represent the simplification (no suffix) and cover all the scenarios mentioned here.\n\n[1] https://review.opendev.org/#/c/658192/4","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"66a8b87528882876e3fed0d54f4e01df63953c0e","unresolved":false,"context_lines":[{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":"**Use case:** My cloud includes hosts modeled with NUMA layouts, such that"},{"line_number":73,"context_line":"inventories of ``VCPU`` and ``MEMORY_MB`` are divided among multiple resource"},{"line_number":74,"context_line":"providers. I want to be able to design flavors for instances that *don\u0027t care"},{"line_number":75,"context_line":"about NUMA affinity* but can still land on such hosts. Further, I want to"},{"line_number":76,"context_line":"maximize the probability that the instance can still land on a host where the"},{"line_number":77,"context_line":"required amount of a given resource is only satisfied when available"},{"line_number":78,"context_line":"inventories of multiple providers are considered in sum."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_342bab30","line":75,"range":{"start_line":74,"start_character":11,"end_line":75,"end_character":54},"updated":"2019-05-27 05:41:38.000000000","message":"For today, Nova supports to mix the non-NUMA instance and NUMA instance into the same host.\n\n\nThe non-NUMA instance\u0027s VCPUs are floating on all the host PCPUs. (Actually, running at which PCPU is decided by the Linux scheduler)\n\nThe NUMA instance\u0027s VCPUs are 1:1 pinning to host PCPUs.\n\n\nAnd then, both of non-NUMA instance and NUMA instance\u0027s memory are allocated from the NUMA node of his VCPUs running on.\n\n\nUsing the same example in line 92, I have a NUMA instance with 2 NUMA nodes and requires 1024 MB in each NUMA node. So it consumes 1024MB memory in each host NUMA node.\n\nAnd I have another non-NUMA instance with 2048MB and 1 VCPU. And assume the Linux scheduler letting the instance running on the host numa0.\n\n\nWhen the non-NUMA instance already uses 1536MB in host numa0 node, the NUMA instance already uses 512MB in host numa0(1536+512\u003d2048, the numa0 is full), then both instances want more memory. What is Linux behavior? Will Linux asks NUMA instance to allocate memory from remote NUMA node, or Linux asks non-NUMA instance to allocate memory from remote NUMA node?\n\n\nIf the Linux may ask NUMA instance to allocate memory from remote NUMA node, then the NUMA instance can\u0027t get performance guarantee. So the final question is: whether mixing the NUMA instance and non-NUMA instance on the same host make sense or not?","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df23f11f1efbdf9411ca9f1c2ed8b84754041820","unresolved":false,"context_lines":[{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":"**Use case:** My cloud includes hosts modeled with NUMA layouts, such that"},{"line_number":73,"context_line":"inventories of ``VCPU`` and ``MEMORY_MB`` are divided among multiple resource"},{"line_number":74,"context_line":"providers. I want to be able to design flavors for instances that *don\u0027t care"},{"line_number":75,"context_line":"about NUMA affinity* but can still land on such hosts. Further, I want to"},{"line_number":76,"context_line":"maximize the probability that the instance can still land on a host where the"},{"line_number":77,"context_line":"required amount of a given resource is only satisfied when available"},{"line_number":78,"context_line":"inventories of multiple providers are considered in sum."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_5c588854","line":75,"range":{"start_line":74,"start_character":11,"end_line":75,"end_character":54},"in_reply_to":"bfb3d3c7_2c7569fa","updated":"2019-05-30 13:07:35.000000000","message":"yes its an English problem on my side :)\n\nit should have read\n\n\"we explictly recommend that you should never mix numa isntances with non numa instances on the same host. if you are using cpu pinning or hugepages  the instance is a numa instance.\"\n\nthe reason for this is the 4k page issue and OOM reaping behavior.\n\nif we expose the two memory backing files as a single guest numa node the memory allcoation made by the guest will not nessisarly corralte to which vcpu the app is running on.\n\nwhat the guest os will see would be 2 dimms different size.\nbut they would be both connected to the same virtual nuam node/ memory controller in the guest. \n\ni dont think the vm would be any more at risk of being selected by OOM killer for reaping with this model then when entirly floating. unlink hugepage memory it would still be swapable so if the kernel was low on memory it would first page the guest memroy out and only trigger OOM if it could still not free enough memory. if you use a ram allcoation ratio \u003e1 you are ment to allocate enough swap space to allow over allocation so i think you would be fine. that said i always think its a bad idea to overallocate ram so personally i would always set it to 1.0 or use huegepages.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":"**Use case:** My cloud includes hosts modeled with NUMA layouts, such that"},{"line_number":73,"context_line":"inventories of ``VCPU`` and ``MEMORY_MB`` are divided among multiple resource"},{"line_number":74,"context_line":"providers. I want to be able to design flavors for instances that *don\u0027t care"},{"line_number":75,"context_line":"about NUMA affinity* but can still land on such hosts. Further, I want to"},{"line_number":76,"context_line":"maximize the probability that the instance can still land on a host where the"},{"line_number":77,"context_line":"required amount of a given resource is only satisfied when available"},{"line_number":78,"context_line":"inventories of multiple providers are considered in sum."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_e96687c1","line":75,"range":{"start_line":74,"start_character":11,"end_line":75,"end_character":54},"in_reply_to":"bfb3d3c7_342bab30","updated":"2019-05-28 17:28:21.000000000","message":"that is not entirly correct.\n\nwe explictly recommend that you should never mix numa isntance with non numa instance on the same host but if you are using cpu pinning or hugepages for the numa instances.\n\nnot all numa instace are have there vcpus pinned 1:1 to host cpus. that only happens if you enable cpu pinning. if you have a numa topology because you set hw:numa_nodes\u003dX or you enabled hugepages without cpu pinning then the guest vcpus are pined to teh set of cores within a given numa node.\n\nso each vcpu is pinned to a set of host cpus and can float\nover that set.\n\nwe are chaing the behavior of non numa guest to nolonger float over all cpus as part of the modeling vcpu and pcpus in placement spec. once implemented .e.g in trian non numa instance and all instance that do not enable cpu pinning will be partally pinned the same way that numa instace without pinnign are partially pinned today.\n\nthat is to say there vcpus will be each pinned to the set of host core that are listed in the cpu_shared_set. similarly numa instance that dont have cpu pinning enabled will also be pined to a numa local subset of the cpu_shared_set host cores.\n\nregarding the senario you proved if we allowed the above configuration to work then when the memory on the host numa node is exausted the OOM killer will reap a running process on node 0 likely killing on of the vms.\n\nthis is why we do not recommend mixing numa and non numa isntance on the same host today and state that operator should use host aggrates to seperate there numa and non numa instances.\n\nbut we have other options.\n\nfirst if you dont set hw:numa_nodes in you config there is no api restiction on a virt driver providing you with muliple numa nodes.\n\nthe contianer and baremetal vitr driver dont use that config option to enable scheduling to numa hosts so wether you get a instance with 1 or more virtual numa nodes when you dont state anything about the numa topology is an internal implementaion detail of the virt driver.\n\nso we have several options here.\nfirst if placement returend 2 allocations for ram\nwe could reate 2 memory backing files in the livbrt xml\nand afinities both to the numa nodes corresponing to the allocation.  we can then chose to present that to the guest as a singel numa node or expose both as seperate vNUMA nodes.\n\nwhile exposing it as 2 vNUMA node would be better for performance it would possible cause issue for live migration\nso we would likely want expose both backing files as a singel guest numa node.\n\n\nthe rest of this is libvirt specrici so you can ignore if you are not interested. we would do this using the numatune element\n\nhttps://libvirt.org/formatdomain.html#elementsNUMATuning\n\n  \u003cnumatune\u003e\n    \u003cmemnode cellid\u003d\"0\" mode\u003d\"strict\" nodeset\u003d\"0\"/\u003e\n    \u003cmemnode cellid\u003d\"1\" mode\u003d\"strict\" nodeset\u003d\"2\"/\u003e\n  \u003c/numatune\u003e\n\nor\n  \u003cnumatune\u003e\n    \u003cmemnode cellid\u003d\"0\" mode\u003d\"strict\" nodeset\u003d\"0\"/\u003e\n    \u003cmemnode cellid\u003d\"0\" mode\u003d\"strict\" nodeset\u003d\"2\"/\u003e\n  \u003c/numatune\u003e\n\n\ncellid is the guest logical numa cell \nand nodeset is the set of host numa nodes that it will be mapped too.\n\nin combination with the numatune element in the multi numa case we can use numa element to specify how large the allocation is on each numa node.\n\n\u003cnuma\u003e\n    \u003ccell id\u003d\u00270\u0027 cpus\u003d\u00270-3\u0027 memory\u003d\u0027512000\u0027 unit\u003d\u0027KiB\u0027 discard\u003d\u0027yes\u0027/\u003e\n    \u003ccell id\u003d\u00271\u0027 cpus\u003d\u00274-7\u0027 memory\u003d\u0027512000\u0027 unit\u003d\u0027KiB\u0027 memAccess\u003d\u0027shared\u0027/\u003e\n  \u003c/numa\u003e\n\nif we chose to expose ti as a singel numa node we woudl have to use the memory device element directly to ensure that we had one memoy device pre allocate retruned form placmenet.\n\nhttps://libvirt.org/formatdomain.html#elementsMemory\n\n  \u003cmemory model\u003d\u0027dimm\u0027\u003e\n    \u003csource\u003e\n      \u003cpagesize unit\u003d\u0027KiB\u0027\u003e4096\u003c/pagesize\u003e\n      \u003cnodemask\u003e1\u003c/nodemask\u003e\n    \u003c/source\u003e\n    \u003ctarget\u003e\n      \u003csize unit\u003d\u0027KiB\u0027\u003e524287\u003c/size\u003e\n      \u003cnode\u003e0\u003c/node\u003e\n    \u003c/target\u003e\n  \u003c/memory\u003e\n\nnodemask in the source section is the host numa to allocate the memroy from. the page size is opttional. node in the target section is the virtual guest numa node.\n\nat the end of the day if the virt driver reports seperate inventories of cpus and memory per numa node then it needs to support allocating memory to the guest with teh same granuality it reported it.\n\nlibvirt can do this today. the libvirt virt driver would need work but it could do this also.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":8768,"name":"Chris Friesen","email":"chris.friesen@windriver.com","username":"cbf123"},"change_message_id":"708a069061106e02ee4bdcc7e5a949ad2ba54930","unresolved":false,"context_lines":[{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":"**Use case:** My cloud includes hosts modeled with NUMA layouts, such that"},{"line_number":73,"context_line":"inventories of ``VCPU`` and ``MEMORY_MB`` are divided among multiple resource"},{"line_number":74,"context_line":"providers. I want to be able to design flavors for instances that *don\u0027t care"},{"line_number":75,"context_line":"about NUMA affinity* but can still land on such hosts. Further, I want to"},{"line_number":76,"context_line":"maximize the probability that the instance can still land on a host where the"},{"line_number":77,"context_line":"required amount of a given resource is only satisfied when available"},{"line_number":78,"context_line":"inventories of multiple providers are considered in sum."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9fb8cfa7_8f19877a","line":75,"range":{"start_line":74,"start_character":11,"end_line":75,"end_character":54},"in_reply_to":"bfb3d3c7_5c588854","updated":"2019-06-04 18:57:02.000000000","message":"For what it\u0027s worth, we run compute nodes with no swap for predictable performance so OOM is still an issue.\n\nI think the real solutions are to either restrict non-numa instances with 4K pages to a single numa node (rather than letting them float across the whole host) or else remove the \"strict\" memory affinity for 4K pages (so that if we run out of 4k pages on the local NUMA node we can allocate from another NUMA node).","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9b0b29070c6515c10bea0686087c2c6a414cf6af","unresolved":false,"context_lines":[{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":"**Use case:** My cloud includes hosts modeled with NUMA layouts, such that"},{"line_number":73,"context_line":"inventories of ``VCPU`` and ``MEMORY_MB`` are divided among multiple resource"},{"line_number":74,"context_line":"providers. I want to be able to design flavors for instances that *don\u0027t care"},{"line_number":75,"context_line":"about NUMA affinity* but can still land on such hosts. Further, I want to"},{"line_number":76,"context_line":"maximize the probability that the instance can still land on a host where the"},{"line_number":77,"context_line":"required amount of a given resource is only satisfied when available"},{"line_number":78,"context_line":"inventories of multiple providers are considered in sum."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_e90d15e8","line":75,"range":{"start_line":74,"start_character":11,"end_line":75,"end_character":54},"in_reply_to":"bfb3d3c7_a3809cf6","updated":"2019-05-29 13:04:38.000000000","message":"it could change over move operations but yes if we report resouce in a granular/numa way to palcement we shoudl respect the allocation retruned by placmeent to ensure we dont get our of sync. \n\nmy view is if we tell placement we need a quantity of a resouces and say it can be split then we shoudl ensure at the host level we consuem the resouces in accordance with the allocations placement returned.\n\nmeaning for ram if we get one allocation from numa0 RP then we shoudl ensure all guest memory is allocated form host numa node 0\n\nif we get two allocations 512mb form numa0 rp and 1536 form numa1 rp then we shoudl allocate memory in that proportion form the host numa nodes.\n\nthe question of numa affinity of cpus and or if we expose this to the guest is really a nova one and we have several options. \n\nnova could ignore the numa affintiy of the cpus and jsut allow the vm to float with pinned memory that is totally valid as you have not asked for nuam affintiy by setting hw:numa_nodes\u003d1 so the kenel could have allocated the memory form both numa nodes like that anyway.\n\nif we choose to reflect the topogy of the alloations to the guest the only case where that is an issue is livemigration where it cant change however we dont need to expose it to the guest even though that will result in the best performacne.\n\nin reality placement would have also provided allcoations for the vcpus so that would have determinted what numa nodes the vm would float over.\n\nnova would be perfectly free to implement a weigher that used the provider summaries to prefer selecting hosts with optimal numa affinity but since these guest have no numa requests in the flavor or image this is purely an optimization not a requirement.for numa aware gusts we will not use can split and will use granular request grops so the weigher is not need in that case.\n\nso for me yes the important thing is ensuring that the host and placement dont get out of sync but the virt driver ignoring how the allocation are split and also not imposing constraints on placement that are optimizations that can be done client side.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"3947fb9b7ce6b28646c417fd13c7da01c456aec8","unresolved":false,"context_lines":[{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":"**Use case:** My cloud includes hosts modeled with NUMA layouts, such that"},{"line_number":73,"context_line":"inventories of ``VCPU`` and ``MEMORY_MB`` are divided among multiple resource"},{"line_number":74,"context_line":"providers. I want to be able to design flavors for instances that *don\u0027t care"},{"line_number":75,"context_line":"about NUMA affinity* but can still land on such hosts. Further, I want to"},{"line_number":76,"context_line":"maximize the probability that the instance can still land on a host where the"},{"line_number":77,"context_line":"required amount of a given resource is only satisfied when available"},{"line_number":78,"context_line":"inventories of multiple providers are considered in sum."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2c7569fa","line":75,"range":{"start_line":74,"start_character":11,"end_line":75,"end_character":54},"in_reply_to":"bfb3d3c7_e96687c1","updated":"2019-05-30 08:26:18.000000000","message":"\u003e we explictly recommend that you should never mix numa isntance with\n \u003e non numa instance on the same host but if you are using cpu pinning\n \u003e or hugepages for the numa instances.\n\nNot sure whether it is English problem, I may misunderstand you. I guess you typing wrong, I think we should on the same page\n\nWe only recommend that user should never mix pinned and non-pinned instance on the same host. We didn\u0027t say about never mix non-pinned numa instance and non-pinned non-numa instance on the same host.\n\nWe write it at here https://docs.openstack.org/nova/latest/admin/cpu-topologies.html#customizing-instance-cpu-pinning-policies\n\n \u003e \n \u003e regarding the senario you proved if we allowed the above\n \u003e configuration to work then when the memory on the host numa node is\n \u003e exausted the OOM killer will reap a running process on node 0\n \u003e likely killing on of the vms.\n \u003e \n \u003e this is why we do not recommend mixing numa and non numa isntance\n \u003e on the same host today and state that operator should use host\n \u003e aggrates to seperate there numa and non numa instances.\n \u003e \n\nThanks, that is what answer I wanted, so that means we should not supporting mixing non-pinned numa and non-pinned non-numa instance on the same host.\n\n \u003e so we have several options here.\n \u003e first if placement returend 2 allocations for ram\n \u003e we could reate 2 memory backing files in the livbrt xml\n \u003e and afinities both to the numa nodes corresponing to the\n \u003e allocation.  we can then chose to present that to the guest as a\n \u003e singel numa node or expose both as seperate vNUMA nodes.\n\nI\u0027m not sure I like this options, but it is interesting.\n\nIn first case, we probably have 1MB in first numa, all of rest memory in the other numa...yes, that is policy can be tuning. Will that confusing the guest tuning his application based on the numa?\n\n \u003e \n \u003e while exposing it as 2 vNUMA node would be better for performance\n \u003e it would possible cause issue for live migration\n\n \u003e so we would likely want expose both backing files as a singel guest\n \u003e numa node.\n \nFor this case, we still need cpu pinning, pinning the vCPU to a set of host cpus. And allocate memory from two different host numa nodes.\n\nI guess that will have the same issue on the case what I said above. If there is an application running on a specific vCPU inside the guest, and that vCPU is pinning to a host numa node, and when that application is looking for more memory than that we allocated for it in that host numa node, OOM will kill the VM again.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"5ab7191c2c19cf9caad21320039f6a87587f70f1","unresolved":false,"context_lines":[{"line_number":71,"context_line":"---------"},{"line_number":72,"context_line":"**Use case:** My cloud includes hosts modeled with NUMA layouts, such that"},{"line_number":73,"context_line":"inventories of ``VCPU`` and ``MEMORY_MB`` are divided among multiple resource"},{"line_number":74,"context_line":"providers. I want to be able to design flavors for instances that *don\u0027t care"},{"line_number":75,"context_line":"about NUMA affinity* but can still land on such hosts. Further, I want to"},{"line_number":76,"context_line":"maximize the probability that the instance can still land on a host where the"},{"line_number":77,"context_line":"required amount of a given resource is only satisfied when available"},{"line_number":78,"context_line":"inventories of multiple providers are considered in sum."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_a3809cf6","line":75,"range":{"start_line":74,"start_character":11,"end_line":75,"end_character":54},"in_reply_to":"bfb3d3c7_e96687c1","updated":"2019-05-29 11:03:07.000000000","message":"It sounds like a main concern with can_split is making sure that if it is used, that the mode of the split remain true through the lifetime of the instance so that placement\u0027s and the host\u0027s representation of usage doesn\u0027t get out of sync.\n\nIs that correct?","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":110,"context_line":"would produce the following three permutations for ``VCPU``::"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":" numa0  numa1"},{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_326bd085","line":113,"updated":"2019-05-24 13:42:04.000000000","message":"In this case will the returned candidate will mention numa0 at all? I guess not. Which is OK.\n\n// later\n\nOK in this example numa0 will be returned as it alway provide some amount of memory too.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1dd32b1a7f0c0d1ec5aabde02938bcf55b0ad8f8","unresolved":false,"context_lines":[{"line_number":110,"context_line":"would produce the following three permutations for ``VCPU``::"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":" numa0  numa1"},{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_85fb4345","line":113,"in_reply_to":"bfb3d3c7_09be9ed4","updated":"2019-05-27 17:10:18.000000000","message":"Cool. The providers summaries behavior also works for me.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"c2e7a8102c0e8fbd928eedab326572029799e612","unresolved":false,"context_lines":[{"line_number":110,"context_line":"would produce the following three permutations for ``VCPU``::"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":" numa0  numa1"},{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_09be9ed4","line":113,"in_reply_to":"bfb3d3c7_326bd085","updated":"2019-05-24 20:17:44.000000000","message":"Your point is valid, though. If there were a viable combination that had no resources from numa0, it wouldn\u0027t have an allocation entry in the dict.\n\n(Note that it *would* still show up in provider_summaries, because at some point we made provider_summaries contain all the providers in the tree. That has nothing to do with this work.)","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":110,"context_line":"would produce the following three permutations for ``VCPU``::"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":" numa0  numa1"},{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_89110b60","line":113,"in_reply_to":"bfb3d3c7_85fb4345","updated":"2019-05-28 17:28:21.000000000","message":"so to carify we would only have allcation form numa0 if we consumed resouces or traits provdied by the numa0 RP right.\nso if both the cpu and ram were form numa1 then we would not have an allocation form numa0 unless there was some other resocse like a disk or nic that was proved by numa0","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"85aa65dde182604b6049584f1ac183c7b069ba65","unresolved":false,"context_lines":[{"line_number":110,"context_line":"would produce the following three permutations for ``VCPU``::"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":" numa0  numa1"},{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_ed9bec6f","line":113,"in_reply_to":"bfb3d3c7_89110b60","updated":"2019-05-29 20:10:17.000000000","message":"correct. (Except for the \"or traits\" part - if we satisfied part of the request with a \"resourceless provider\" by matching *only* a trait (but no resources) from numa0, then numa0 still won\u0027t show up in the allocations, because allocations by definition are for resources. But it does show up in the provider summaries. And presumably when we do the rg/rp mapping, it will show up appropriately there.)","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df23f11f1efbdf9411ca9f1c2ed8b84754041820","unresolved":false,"context_lines":[{"line_number":110,"context_line":"would produce the following three permutations for ``VCPU``::"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":" numa0  numa1"},{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_3c37d401","line":113,"in_reply_to":"bfb3d3c7_ed9bec6f","updated":"2019-05-30 13:07:35.000000000","message":"gotcha, makes sense. i was assuming numa0 was a resoucesless provider but i was a little imprecise in my wording.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"4f91f5fb11ace50c81ccce03a05bc8f2a0b6c4ce","unresolved":false,"context_lines":[{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"and the following four permutations for ``MEMORY_MB``::"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":" numa0  numa1"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_1381e44a","line":116,"updated":"2019-05-25 09:32:52.000000000","message":"Just to be clear, today Nova (or OpenStack) does not have the responsibility to decide the numbers of vCPU usage for each NUMA node. It\u0027s user\u0027s responsibility to decide how many vCPUs they want on each instance NUMA nodes [1] on the instance deployment (even if it is not dedicated CPUs).\n\n[1] https://docs.openstack.org/nova/pike/admin/cpu-topologies.html#customizing-instance-numa-placement-policies\n\nSo this is a use case that is not supported in Nova today, and I\u0027d like to see the specific use case in Nova before getting this on the train.\n\nIf I\u0027m not wrong, that would be something like:\n\nI want to enable users to specify that \"I want an instance that is not NUMA unaware, but if the resource is not enough I don\u0027t mind if that instance ends up being NUMA aware\"\n\n...or are you trying to enable collocation of NUMA aware/un-aware instances on a same host with this feature? (Note that we are going to enable CPU pinning/non-pinning instances to collocate on a same host with the PCPU tracking spec, but collocation of NUMA aware-unaware instances on a same host is not the scope so far)","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b9ae64f4bf9a172944f75d839f6f128d2281e6fa","unresolved":false,"context_lines":[{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"and the following four permutations for ``MEMORY_MB``::"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":" numa0  numa1"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_73fb8046","line":116,"in_reply_to":"bfb3d3c7_1381e44a","updated":"2019-05-25 13:45:00.000000000","message":"\u003e ...or are you trying to enable collocation of NUMA aware/un-aware\n \u003e instances on a same host with this feature?\n\nThis.\n\nToday if your flavor specifies a NUMA topology, you\u0027ll land on a host that passes the NUMATopologyFilter and your CPUs and memory will be assigned according to the layout you describe. We can do that with placement today (as long as you\u0027re not asking for any devices to go with your proc/mem - to enable affinity with devices we need same_subtree.)\n\nBut today if your flavor does *not* specify a NUMA topology, you can *still* land on the above host as long as enough resource is available across *all* NUMA nodes. This is where we would break without can_split.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"ab67614d8a174f510a935f7f46dc8160bff604ef","unresolved":false,"context_lines":[{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"and the following four permutations for ``MEMORY_MB``::"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":" numa0  numa1"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_b9f799d3","line":116,"in_reply_to":"bfb3d3c7_73fb8046","updated":"2019-05-26 06:41:58.000000000","message":"That means a user could end up with getting 1-NUMA node or 2-NUMA node instance [1] while they requested a non-NUMA node instance, right?\n\n[1] https://docs.openstack.org/nova/latest/contributor/testing/libvirt-numa.html#testing-instance-boot-with-2-numa-cells-requested\n\nAs far as I know, one NUMA node instance and non-NUMA node instance are different in today\u0027s OpenStack/Nova world (with libvirt driver). One NUMA node instance sticks its virtual memory to memory on one physical node [1], while non-NUMA node instance does nothing for that kind of tuning.\n\nIOW, non-NUMA node instance does not have a capability to use memory from each crisp node as placement suggests like \"okay, use 1024MB from node0 and 2048MB from node1\".\n\n...and I think that is True as long as libvirt\u0027s IF to stick virtual-physical memory node uses the virtual numa node cell id.\n[2] https://libvirt.org/formatdomain.html#elementsNUMATuning","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"4eb504b877b0cb6d933399e9e5ac8a5f5c8f66b1","unresolved":false,"context_lines":[{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"and the following four permutations for ``MEMORY_MB``::"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":" numa0  numa1"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_f9167155","line":116,"in_reply_to":"bfb3d3c7_b9f799d3","updated":"2019-05-26 12:16:25.000000000","message":"Let me make sure I understand the distinction you\u0027re making.\n\nToday\u0027s non-NUMA instance can float its CPU and memory across multiple host NUMA cells, but with all of this new work in place libvirt will have no choice but to pin them to whatever cells the allocation happened to land on. And in the worst case this could lead to the CPU and memory being on different cells, and stuck there for the life of the VM, whereas in the old world there would have been at least the possibility that they would at some point get shuffled around to affine.\n\nThis is true. But if you\u0027ve said you want a non-NUMA instance, what you\u0027re really saying is you want an instance that doesn\u0027t care about that level of performance anyway.\n\nThe alternative is to land your instance only on nodes that are not modeling   NUMA topology. Which you could also do, if you cared, by forbidding the HW_NUMA_ROOT trait. But that is going to limit where you can land, possibly frequently to the point of NoValidHost.\n\nSo the whole point of can_split is to enable my \"I really don\u0027t care about NUMA\" instance to land on a host that is set up with NUMA modeling, even (especially) if no one NUMA node has enough resource by itself.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"and the following four permutations for ``MEMORY_MB``::"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":" numa0  numa1"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_ccde3110","line":116,"in_reply_to":"bfb3d3c7_c04cc943","updated":"2019-05-28 17:28:21.000000000","message":"if the guest does not specyify a numa topolgoy its virt driver specifci if ti has a numa toplogy or not.\n\nthey are not requsting a guest with out a numa toplogy.\nthe libvirt dirver and most other will default that guest to 1 virtula numa node but we will not affinities that guest to a singel host numa node.\n\nwe shoudl not conflate the guest numa toplogy and the affintiy of that numa topology to the host.\n\nthe container and baremental virt drivers do not present a singel numa node to the guest if the host has multiple numa ndoes. so that is not part of the api contract even if that is what we default to in libvirt.\n\nwe already agreed to do partial pininng of non pinned instace as part of the pcpu in placmeent spec. specficly guest without hw:cpu_policy\u003ddedeicated will be partial pinniend so that there vcpus can float only over the cores within the cpu_shared_set. that is a 1:n relationship rathter then the 1:1 relationship that we create for the for pinned instances.\n\n\ne.g. \n  \u003cvcpupin vcpu\u003d\"0\" cpuset\u003d\"1-2,6-8\"/\u003e\n  \u003cvcpupin vcpu\u003d\"1\" cpuset\u003d\"1-2,6-8\"/\u003e\n  \u003cvcpupin vcpu\u003d\"2\" cpuset\u003d\"1-2,6-8\"/\u003e\n  \u003cvcpupin vcpu\u003d\"3\" cpuset\u003d\"1-2,6-8\"/\u003e\n\n\nim assume host cores 0-3 are on numa node 0 and\nand cores 4-7 are on numa node 2\nand im assuming the cpu_shared_set is 1-3,6-8\n\nin this example the guest has 4 vcpus that are\npartially pinned to only float over the cpus\nlisted in teh cpu_shared_set.\n\nif i recived 2 allcoations fo vcpus form placement\ni can model this in two ways in the virt dirver.\nfirst as i did above \n\n  \u003cvcpupin vcpu\u003d\"0\" cpuset\u003d\"1-3,6-8\"/\u003e\n  \u003cvcpupin vcpu\u003d\"1\" cpuset\u003d\"1-3,6-8\"/\u003e\n  \u003cvcpupin vcpu\u003d\"2\" cpuset\u003d\"1-3,6-8\"/\u003e\n  \u003cvcpupin vcpu\u003d\"3\" cpuset\u003d\"1-3,6-8\"/\u003e\n\n\nor second i could refect that say 3 came for numa node0 rp and 1 form the numa node 1 rp\n\n\u003cvcpupin vcpu\u003d\"0\" cpuset\u003d\"1-3\"/\u003e\n\u003cvcpupin vcpu\u003d\"1\" cpuset\u003d\"1-3\"/\u003e\n\u003cvcpupin vcpu\u003d\"2\" cpuset\u003d\"1-3\"/\u003e\n\u003cvcpupin vcpu\u003d\"3\" cpuset\u003d\"6-8\"/\u003e\n\nin both cases the guest will not be able to detect\nthis as the way the vcpus are exposed to the guest kernel will not change. this is purly an implementaion detail\nthat the virt driver is free to chose today when you have\nnot specified any numa or pinning requirements.\n\nthe hw_cpu_* element are also irrelevent to the placement conversattion as they spefyc how the cpus will be presented to teh guest os and do not impact schulding or placmenet in anyway. e.g. they dont affect the guest to host mapping, or allocations.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"66a8b87528882876e3fed0d54f4e01df63953c0e","unresolved":false,"context_lines":[{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"and the following four permutations for ``MEMORY_MB``::"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":" numa0  numa1"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_b17b2dbc","line":116,"in_reply_to":"bfb3d3c7_f9167155","updated":"2019-05-27 05:41:38.000000000","message":"\u003e Let me make sure I understand the distinction you\u0027re making.\n \u003e \n \u003e Today\u0027s non-NUMA instance can float its CPU and memory across\n \u003e multiple host NUMA cells, but with all of this new work in place\n \u003e libvirt will have no choice but to pin them to whatever cells the\n \u003e allocation happened to land on. And in the worst case this could\n \u003e lead to the CPU and memory being on different cells, and stuck\n \u003e there for the life of the VM, whereas in the old world there would\n \u003e have been at least the possibility that they would at some point\n \u003e get shuffled around to affine.\n\nThis is bad. And if libvirt is going to pin the non-numa instance\u0027s vcpu to pcpu, then this isn\u0027t the case we have in Nova today.\n\nWhat we have today is that the non-numa instance\u0027s vcpus are floating on all the host pcpus.\n\nSo if libvirt isn\u0027t going to pin the vcpu to pcpu for non-numa instance, then that violated the allocation we have in the placement.\n\nFor example, we choice to allocate 0 vcpu in numa0, and allocate 4 vcpus in numa1. But the linux process scheduler may let those 4 vcpus running on the numa0.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"7f99e8a4d67ca17371222a39693eebc0494894d9","unresolved":false,"context_lines":[{"line_number":113,"context_line":"     0      4  # NOTE: can_split doesn\u0027t mean must_split"},{"line_number":114,"context_line":"     1      3"},{"line_number":115,"context_line":"     2      2"},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"and the following four permutations for ``MEMORY_MB``::"},{"line_number":118,"context_line":""},{"line_number":119,"context_line":" numa0  numa1"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_c04cc943","line":116,"in_reply_to":"bfb3d3c7_f9167155","updated":"2019-05-28 02:53:29.000000000","message":"\u003e So the whole point of can_split is to enable my \"I really don\u0027t\n \u003e care about NUMA\" instance to land on a host that is set up with\n \u003e NUMA modeling, even (especially) if no one NUMA node has enough\n \u003e resource by itself.\n\n...by making that instance an NUMA-aware instance.\n^My point is that this has considerable side effects.\nFirst, we don\u0027t support some features for NUMA instances such as live migration at least for now. Second, it should go through the NUMATopologyFilter making the deployment slower, and... will nova try other permutations placement suggested while NUMATopologyFilter says nein due to more detailed e.g. hugepage memory check? If not, this is just one or several whimsy retries, which can be reasonably done by users setting numa explicitly for their flavor and try again.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  1280      0"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Candidate Explosion"},{"line_number":128,"context_line":"~~~~~~~~~~~~~~~~~~~"},{"line_number":129,"context_line":"There is concern that ``can_split`` on resource classes whose inventories"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_b20b407b","line":126,"updated":"2019-05-24 13:42:04.000000000","message":"Just to make sure: If during can_split calculation placement selects two PRs to provide resource FOO. Then the traits and aggregate membership of both RPs will considered to see if two RPs are a good match for the request from traits and aggregate membership perspective.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"3235fc5c49a86e73743b6858738d0400e2523466","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  1280      0"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Candidate Explosion"},{"line_number":128,"context_line":"~~~~~~~~~~~~~~~~~~~"},{"line_number":129,"context_line":"There is concern that ``can_split`` on resource classes whose inventories"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_ea6a19eb","line":126,"in_reply_to":"bfb3d3c7_09a3feb3","updated":"2019-05-24 22:43:34.000000000","message":"\u003e Good test case to make sure we cover, though. Put a trait on one\n \u003e NUMA node but not the other, require (or forbid) that trait in a\n \u003e request including can_split, and make sure only the right NUMA node\n \u003e features in the result.\n\nDone in https://review.opendev.org/#/c/658192/4","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"c2e7a8102c0e8fbd928eedab326572029799e612","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  1280      0"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Candidate Explosion"},{"line_number":128,"context_line":"~~~~~~~~~~~~~~~~~~~"},{"line_number":129,"context_line":"There is concern that ``can_split`` on resource classes whose inventories"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_09a3feb3","line":126,"in_reply_to":"bfb3d3c7_b20b407b","updated":"2019-05-24 20:17:44.000000000","message":"Yes. I imagine for efficiency we should *first* find all the providers matching trait \u0026 aggregate filters and containing *any* resource of *any* of the classes in play, and *then* go to work figuring out available resources on them.\n\nGood test case to make sure we cover, though. Put a trait on one NUMA node but not the other, require (or forbid) that trait in a request including can_split, and make sure only the right NUMA node features in the result.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1dd32b1a7f0c0d1ec5aabde02938bcf55b0ad8f8","unresolved":false,"context_lines":[{"line_number":123,"context_line":"  1280      0"},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Candidate Explosion"},{"line_number":128,"context_line":"~~~~~~~~~~~~~~~~~~~"},{"line_number":129,"context_line":"There is concern that ``can_split`` on resource classes whose inventories"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_053993f0","line":126,"in_reply_to":"bfb3d3c7_ea6a19eb","updated":"2019-05-27 17:10:18.000000000","message":"thanks.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"96bd530a1d5f3d2c3b29822c70ec78e9c830915c","unresolved":false,"context_lines":[{"line_number":125,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Candidate Explosion"},{"line_number":128,"context_line":"~~~~~~~~~~~~~~~~~~~"},{"line_number":129,"context_line":"There is concern that ``can_split`` on resource classes whose inventories"},{"line_number":130,"context_line":"have large totals - e.g. ``MEMORY_MB`` - could result in an unmanageable number"},{"line_number":131,"context_line":"of permutations. As shown in the example above, this can mitigated by careful"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_11feb96a","line":128,"range":{"start_line":128,"start_character":1,"end_line":128,"end_character":19},"updated":"2019-05-27 04:35:56.000000000","message":"One more concern.\n\nFor example, the host numa0 has 4 vcpu, and host numa1 has 4 vcpu. The allcoation_ratio is 1.\n\nThe first request  is a non-numa instance which has 4 vcpus. We allocate 4 vcpus in the host numa0 for it.\n\nThen we have second request, it is 2 numa node instance, each numa node needs 2 vcpu. This request will fail on this host.\n\nIf the first no-numa instance, gets 2 vcpus in numa0, and gets 2 vcpus in numa1. Then the second 2 numa nodes instance can load on this host.\n\nSo there needs a strategy on choosing which allocation candidates. I don\u0027t know this strategy decided by who.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1dd32b1a7f0c0d1ec5aabde02938bcf55b0ad8f8","unresolved":false,"context_lines":[{"line_number":125,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Candidate Explosion"},{"line_number":128,"context_line":"~~~~~~~~~~~~~~~~~~~"},{"line_number":129,"context_line":"There is concern that ``can_split`` on resource classes whose inventories"},{"line_number":130,"context_line":"have large totals - e.g. ``MEMORY_MB`` - could result in an unmanageable number"},{"line_number":131,"context_line":"of permutations. As shown in the example above, this can mitigated by careful"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_c014c946","line":128,"range":{"start_line":128,"start_character":1,"end_line":128,"end_character":19},"in_reply_to":"bfb3d3c7_11feb96a","updated":"2019-05-27 17:10:18.000000000","message":"Placement only want to provide viable candidates. But nova-scheduler is the one that select one candidate and allocates accordingly. Today nova only filters and weighs host not candidates for hosts and nova always allocates the first candidate for the host the scheduler selected. To be able to express preference between allocation candidates (on a same host) nova-scheduler needs to start filtering and weighing allocation candidates instead of host.\n\nAlso note that in the current nova model where every server from a set of servers is scheduled alone, independently from others, the scheduling decision will be always suboptimal compared to a model where the same set of server would be scheduled together.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":125,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Candidate Explosion"},{"line_number":128,"context_line":"~~~~~~~~~~~~~~~~~~~"},{"line_number":129,"context_line":"There is concern that ``can_split`` on resource classes whose inventories"},{"line_number":130,"context_line":"have large totals - e.g. ``MEMORY_MB`` - could result in an unmanageable number"},{"line_number":131,"context_line":"of permutations. As shown in the example above, this can mitigated by careful"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_0cf1a995","line":128,"range":{"start_line":128,"start_character":1,"end_line":128,"end_character":19},"in_reply_to":"bfb3d3c7_23ca884d","updated":"2019-05-28 17:28:21.000000000","message":"this is the same class of tetris proble we have today so i agree this shoudl be out of scope of placmeent to solve.\n\nwe cane use weigher or other mechanisumes on the nova side to \noptimise for this without requiring plament to care.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"6b64f3f1ee20d59cfa0d8e50bf8ce563dff18231","unresolved":false,"context_lines":[{"line_number":125,"context_line":"resulting in 3 x 4 \u003d 12 allocation candidates (for this part of the request)."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Candidate Explosion"},{"line_number":128,"context_line":"~~~~~~~~~~~~~~~~~~~"},{"line_number":129,"context_line":"There is concern that ``can_split`` on resource classes whose inventories"},{"line_number":130,"context_line":"have large totals - e.g. ``MEMORY_MB`` - could result in an unmanageable number"},{"line_number":131,"context_line":"of permutations. As shown in the example above, this can mitigated by careful"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_23ca884d","line":128,"range":{"start_line":128,"start_character":1,"end_line":128,"end_character":19},"in_reply_to":"bfb3d3c7_c014c946","updated":"2019-05-28 02:15:59.000000000","message":"Agree with you Nova should be the right place for weighing the candidates. But it is still a very complex weighing.\n\nGood point on suboptimal. One thing may argue is that current nova  model doesn\u0027t have this trouble, the model of this spec introduced this trouble.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":133,"context_line":"absent (they default to 1) or unreasonably low (for some value of"},{"line_number":134,"context_line":"\"unreasonably\"), we may wish to consider using some algorithm to limit the"},{"line_number":135,"context_line":"number of permutations produced. Some discussion on this can be found here:"},{"line_number":136,"context_line":"https://review.opendev.org/#/c/657463/3/placement/tests/functional/fixtures/gabbits.py@471"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"What about sharing providers?"},{"line_number":139,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_f2b9b8cb","line":136,"updated":"2019-05-24 13:42:04.000000000","message":"I left some comment in the code review ^^. I don\u0027t feel that placement should guess a good min_unit and step_size if it is not provided by the client.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":133,"context_line":"absent (they default to 1) or unreasonably low (for some value of"},{"line_number":134,"context_line":"\"unreasonably\"), we may wish to consider using some algorithm to limit the"},{"line_number":135,"context_line":"number of permutations produced. Some discussion on this can be found here:"},{"line_number":136,"context_line":"https://review.opendev.org/#/c/657463/3/placement/tests/functional/fixtures/gabbits.py@471"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"What about sharing providers?"},{"line_number":139,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2c54ad20","line":136,"in_reply_to":"bfb3d3c7_f2b9b8cb","updated":"2019-05-28 17:28:21.000000000","message":"i mention this a bit at the ptg but i do feel haveing a \nmax_candiate_per_host api parameter or placement config option would be a good thing.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":139,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":140,"context_line":"Initially we will **not** split resources from sharing providers, because we"},{"line_number":141,"context_line":"can\u0027t think of a use case where that would be necessary/desirable, and it would"},{"line_number":142,"context_line":"greatly increase the test surface."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"Discussion on this topic can be found here:"},{"line_number":145,"context_line":"https://review.opendev.org/#/c/658510/2/doc/source/specs/train/approved/2005575-nested-magic.rst@153"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_72cdc864","line":142,"updated":"2019-05-24 13:42:04.000000000","message":"agree that we don\u0027t need this feature now so don\u0027t support it now.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":139,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":140,"context_line":"Initially we will **not** split resources from sharing providers, because we"},{"line_number":141,"context_line":"can\u0027t think of a use case where that would be necessary/desirable, and it would"},{"line_number":142,"context_line":"greatly increase the test surface."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"Discussion on this topic can be found here:"},{"line_number":145,"context_line":"https://review.opendev.org/#/c/658510/2/doc/source/specs/train/approved/2005575-nested-magic.rst@153"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_0fe43b3b","line":142,"in_reply_to":"bfb3d3c7_72cdc864","updated":"2019-05-28 17:28:21.000000000","message":"i think it makes sense at least until\nwe have a compelling usecase.\ni can think of one but it a littel contrived.\nso i wont rathole on it.\n+1","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":148,"context_line":"same class, so it will not be an error if the request contains"},{"line_number":149,"context_line":"``can_split\u003dFOO`` and we find an otherwise-appropriate sharing provider"},{"line_number":150,"context_line":"providing ``FOO``. We will simply silently (or perhaps emit a debug log) not"},{"line_number":151,"context_line":"make any attempt to split the ``FOO``."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"For known use cases of sharing - i.e. ``DISK_GB`` - we don\u0027t expect this ever"},{"line_number":154,"context_line":"to come up in real life, as it makes no sense to say ``can_split\u003dDISK_GB``."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_92cf1c55","line":151,"updated":"2019-05-24 13:42:04.000000000","message":"Do you mean placement will drop the sharing RP from the candidate RPs FOO split among.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1dd32b1a7f0c0d1ec5aabde02938bcf55b0ad8f8","unresolved":false,"context_lines":[{"line_number":148,"context_line":"same class, so it will not be an error if the request contains"},{"line_number":149,"context_line":"``can_split\u003dFOO`` and we find an otherwise-appropriate sharing provider"},{"line_number":150,"context_line":"providing ``FOO``. We will simply silently (or perhaps emit a debug log) not"},{"line_number":151,"context_line":"make any attempt to split the ``FOO``."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"For known use cases of sharing - i.e. ``DISK_GB`` - we don\u0027t expect this ever"},{"line_number":154,"context_line":"to come up in real life, as it makes no sense to say ``can_split\u003dDISK_GB``."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_800011ad","line":151,"in_reply_to":"bfb3d3c7_2991224f","updated":"2019-05-27 17:10:18.000000000","message":"OK thanks. I would then suggest: s/to split the ``FOO``./to split the ``FOO`` resources between the sharing and non sharing provider./","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"85aa65dde182604b6049584f1ac183c7b069ba65","unresolved":false,"context_lines":[{"line_number":148,"context_line":"same class, so it will not be an error if the request contains"},{"line_number":149,"context_line":"``can_split\u003dFOO`` and we find an otherwise-appropriate sharing provider"},{"line_number":150,"context_line":"providing ``FOO``. We will simply silently (or perhaps emit a debug log) not"},{"line_number":151,"context_line":"make any attempt to split the ``FOO``."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"For known use cases of sharing - i.e. ``DISK_GB`` - we don\u0027t expect this ever"},{"line_number":154,"context_line":"to come up in real life, as it makes no sense to say ``can_split\u003dDISK_GB``."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2d7fc415","line":151,"in_reply_to":"bfb3d3c7_800011ad","updated":"2019-05-29 20:10:17.000000000","message":"Thanks, will clarify.\n\nBut note that it\u0027s not just between sharing and non-sharing providers. If we had more than one sharing provider with FOO inventory, we also won\u0027t try to split the FOO across those providers.\n\nSo the point is that we won\u0027t try to split the FOO on any sharing providers.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"c2e7a8102c0e8fbd928eedab326572029799e612","unresolved":false,"context_lines":[{"line_number":148,"context_line":"same class, so it will not be an error if the request contains"},{"line_number":149,"context_line":"``can_split\u003dFOO`` and we find an otherwise-appropriate sharing provider"},{"line_number":150,"context_line":"providing ``FOO``. We will simply silently (or perhaps emit a debug log) not"},{"line_number":151,"context_line":"make any attempt to split the ``FOO``."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"For known use cases of sharing - i.e. ``DISK_GB`` - we don\u0027t expect this ever"},{"line_number":154,"context_line":"to come up in real life, as it makes no sense to say ``can_split\u003dDISK_GB``."}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2991224f","line":151,"in_reply_to":"bfb3d3c7_92cf1c55","updated":"2019-05-24 20:17:44.000000000","message":"Not sure I fully understand the question.\n\nWe will still consider the sharing provider. We just won\u0027t try to split its resources. It must provide *all* of the requested amount in the request group, or none of it.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":153,"context_line":"For known use cases of sharing - i.e. ``DISK_GB`` - we don\u0027t expect this ever"},{"line_number":154,"context_line":"to come up in real life, as it makes no sense to say ``can_split\u003dDISK_GB``."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"**Alternative** Support splitting sharing providers. **Rejected** to KISS."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"What about splitting suffixed groups?"},{"line_number":159,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_52d524e4","line":156,"range":{"start_line":156,"start_character":69,"end_line":156,"end_character":73},"updated":"2019-05-24 13:42:04.000000000","message":"+1","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":159,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":160,"context_line":"...i.e. ``can_split$S``."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"**Alternative** This was considered. **Rejected** to KISS, and because any use"},{"line_number":163,"context_line":"cases that were remotely compelling and realistic can be satisfied other ways."},{"line_number":164,"context_line":"https://review.opendev.org/#/c/658510/2/doc/source/specs/train/approved/2005575-nested-magic.rst@134"},{"line_number":165,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_b2fd806f","line":162,"range":{"start_line":162,"start_character":37,"end_line":162,"end_character":49},"updated":"2019-05-24 13:42:04.000000000","message":"Fine by me as I also dont see immediate need for this.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":159,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":160,"context_line":"...i.e. ``can_split$S``."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"**Alternative** This was considered. **Rejected** to KISS, and because any use"},{"line_number":163,"context_line":"cases that were remotely compelling and realistic can be satisfied other ways."},{"line_number":164,"context_line":"https://review.opendev.org/#/c/658510/2/doc/source/specs/train/approved/2005575-nested-magic.rst@134"},{"line_number":165,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_4f755363","line":162,"range":{"start_line":162,"start_character":37,"end_line":162,"end_character":49},"in_reply_to":"bfb3d3c7_b2fd806f","updated":"2019-05-28 17:28:21.000000000","message":"if we were to support it in any case i would want to spcify the can_split per group not gloablly so i also agree we shoudl not do this for now and only consider it if we cant meet a customer usecease.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"96bd530a1d5f3d2c3b29822c70ec78e9c830915c","unresolved":false,"context_lines":[{"line_number":162,"context_line":"**Alternative** This was considered. **Rejected** to KISS, and because any use"},{"line_number":163,"context_line":"cases that were remotely compelling and realistic can be satisfied other ways."},{"line_number":164,"context_line":"https://review.opendev.org/#/c/658510/2/doc/source/specs/train/approved/2005575-nested-magic.rst@134"},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"same_subtree"},{"line_number":167,"context_line":"------------"},{"line_number":168,"context_line":"**Use case:** I want to express affinity between/among allocations in separate"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_11e8f979","line":165,"updated":"2019-05-27 04:35:56.000000000","message":"One more alternative.\n\nseparate the floating vcpus and numa aware vcpus. This is similar with separating the shared and dedicated vcpus.\n\nAllow the operator to decided how much floating vcpus can be running on this host. And how much numa aware vcpus on this host.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":162,"context_line":"**Alternative** This was considered. **Rejected** to KISS, and because any use"},{"line_number":163,"context_line":"cases that were remotely compelling and realistic can be satisfied other ways."},{"line_number":164,"context_line":"https://review.opendev.org/#/c/658510/2/doc/source/specs/train/approved/2005575-nested-magic.rst@134"},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"same_subtree"},{"line_number":167,"context_line":"------------"},{"line_number":168,"context_line":"**Use case:** I want to express affinity between/among allocations in separate"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_afdf2f38","line":165,"in_reply_to":"bfb3d3c7_11e8f979","updated":"2019-05-28 17:28:21.000000000","message":"as i said above.\nwe have change the beahvior of vcpus as part of the pcpu in placmeent spec. now all floating instance will be partially\npinned to the cpus listed in the cpu_shared_set.\n\nso the only difference btween floating instnace with a numa node and without will be numa affined instance will float of a subset of the cpu_shared_set corresponding to the numa node they are assigned too. where as non numa floating instace will be partially pinned to the entire cpu_share_set \nignoring the host numa topology.\n\nthis spec woudl modify that future and all floating instance\nwoudl float over the cores in teh cpu_shared_set correspondint the the numa nodes slected by the placement allocations. the guest them seleve woudl still not get a numa toplogy but thiere memory and cpus would be confined to the phyical resouces that correspond to the RPs there allocation came form to ensure that placment remains authritive.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"3947fb9b7ce6b28646c417fd13c7da01c456aec8","unresolved":false,"context_lines":[{"line_number":162,"context_line":"**Alternative** This was considered. **Rejected** to KISS, and because any use"},{"line_number":163,"context_line":"cases that were remotely compelling and realistic can be satisfied other ways."},{"line_number":164,"context_line":"https://review.opendev.org/#/c/658510/2/doc/source/specs/train/approved/2005575-nested-magic.rst@134"},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"same_subtree"},{"line_number":167,"context_line":"------------"},{"line_number":168,"context_line":"**Use case:** I want to express affinity between/among allocations in separate"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_ec4e7195","line":165,"in_reply_to":"bfb3d3c7_afdf2f38","updated":"2019-05-30 08:26:18.000000000","message":"yes, agree with you, also I\u0027m not sure that change is good.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":191,"context_line":"    +---+--------------+ +---+----------+---+"},{"line_number":192,"context_line":"        |                    |          |"},{"line_number":193,"context_line":"    +---+---+            +---+---+  +---+---+"},{"line_number":194,"context_line":"    |fpga0  |            |fpga1_0|  |fpga1_1|"},{"line_number":195,"context_line":"    |FPGA:1 |            |FPGA:1 |  |FPGA:1 |"},{"line_number":196,"context_line":"    +-------+            +-------+  +-------+"},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2f99ff77","line":194,"range":{"start_line":194,"start_character":5,"end_line":194,"end_character":10},"updated":"2019-05-28 17:28:21.000000000","message":"nit if this was fpga0_0 it would be clearer its modeing node 0 deveice 0 \n\nthe asymitry with the other fpga resouce providers makes the examples on line 207-215 harder to read.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"95a078fafbdceaa5b31766d7938f3e0b79c6bb9f","unresolved":false,"context_lines":[{"line_number":191,"context_line":"    +---+--------------+ +---+----------+---+"},{"line_number":192,"context_line":"        |                    |          |"},{"line_number":193,"context_line":"    +---+---+            +---+---+  +---+---+"},{"line_number":194,"context_line":"    |fpga0  |            |fpga1_0|  |fpga1_1|"},{"line_number":195,"context_line":"    |FPGA:1 |            |FPGA:1 |  |FPGA:1 |"},{"line_number":196,"context_line":"    +-------+            +-------+  +-------+"},{"line_number":197,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_11066a21","line":194,"range":{"start_line":194,"start_character":5,"end_line":194,"end_character":10},"in_reply_to":"bfb3d3c7_2f99ff77","updated":"2019-05-30 22:38:26.000000000","message":"Chris addressed this in https://review.opendev.org/#/c/662191/","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"5b4a1a3a1c4ac9817f683b11a61e78f9d09fbbdd","unresolved":false,"context_lines":[{"line_number":200,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":201,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":202,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":203,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"},{"line_number":204,"context_line":""},{"line_number":205,"context_line":"will produce candidates including::"},{"line_number":206,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_ba18dd1d","line":203,"updated":"2019-05-27 17:52:59.000000000","message":"Can this handle the case of, for example, a VGPU on *one* of our NUMA nodes, but we don\u0027t care which one (which is what Nova does with its current \u0027required\u0027 PCI NUMA policy)?","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":200,"context_line":" ?resources_COMPUTE\u003dVCPU:2,MEMORY_MB:512"},{"line_number":201,"context_line":" \u0026resources_ACCEL\u003dFPGA:1"},{"line_number":202,"context_line":" # NOTE: The suffixes include the leading underscore!"},{"line_number":203,"context_line":" \u0026same_subtree\u003d_COMPUTE,_ACCEL"},{"line_number":204,"context_line":""},{"line_number":205,"context_line":"will produce candidates including::"},{"line_number":206,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_afb88fe4","line":203,"in_reply_to":"bfb3d3c7_ba18dd1d","updated":"2019-05-28 17:28:21.000000000","message":"yes you use \ngroup policy none\nadd teh vgpu to a seperate request group and dont\nspecficy a same_subtree relationship between the VGPU request group and any of the others.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":216,"context_line":""},{"line_number":217,"context_line":"The ``same_subtree`` queryparameter may be repeated. Each grouping is treated"},{"line_number":218,"context_line":"independently."},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Anti-affinity"},{"line_number":221,"context_line":"~~~~~~~~~~~~~"},{"line_number":222,"context_line":"There were discussions about supporting ``!`` syntax in ``same_subtree`` to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_32e2f0a1","line":219,"updated":"2019-05-24 13:42:04.000000000","message":"I think we have a leak here at least on terminology level as the whole the whole tree is a subtree of itself[1]. \n\nI understand the is_same_subtree conditional as defined like A  and B nodes in tree T is in the same subtree iff there exists a subtree in T that contains both A and B.\n\nThere is a definition of _proper_ subtree in [1]:\nBased on that the is_same_proper_subtree conditional can defined as  A and B  nodes in tree T is in the same proper subtree iff there exists a subtree in T that contains both A and B but does not contain the root of T. This subtree is a proper subtree of T.\n\n\nThe selected numa0 and fpga0 RPs are in a subtree defined by the root numa0. (And this subtree is a _proper_ subtree of the tree defined rooted by compute_node.)\n\nBut the not selected num0 and fpga1_0 RPs are also in a same subtree defined by the root compute_node. (However this tree is not a _proper_ subtree of the tree rooted by compute_node.)\n\n\nAre fpga1_0 fpga1_1 considered to be in the same subtree? \n\na) Not as they are not in any kind of parent-child relationships as they are leafs on the same level. e.g. by itself fpga1_0 and fpga1_1 nodes does not define a tree at all.\n\nb) Yes, they are in the same subtree rooted by numa0 and this subtree is a _proper_ subtree of the whole tree rooted by compute_node.\n\nc) Yes they are in the same subtree rooted by compute_node but this tree is _not_ a _proper_ subtree of the whole tree rooted by compute_node.\n\n\n[1]https://en.wikipedia.org/wiki/Tree_(data_structure)#Terminology\n\nDo we have an alternative subtree definition than [1] that clarifies these cases?","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"95a078fafbdceaa5b31766d7938f3e0b79c6bb9f","unresolved":false,"context_lines":[{"line_number":216,"context_line":""},{"line_number":217,"context_line":"The ``same_subtree`` queryparameter may be repeated. Each grouping is treated"},{"line_number":218,"context_line":"independently."},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Anti-affinity"},{"line_number":221,"context_line":"~~~~~~~~~~~~~"},{"line_number":222,"context_line":"There were discussions about supporting ``!`` syntax in ``same_subtree`` to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_c3048917","line":219,"in_reply_to":"bfb3d3c7_2fa7bfa9","updated":"2019-05-30 22:38:26.000000000","message":"Chris addressed this in https://review.opendev.org/#/c/662191/","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"c2e7a8102c0e8fbd928eedab326572029799e612","unresolved":false,"context_lines":[{"line_number":216,"context_line":""},{"line_number":217,"context_line":"The ``same_subtree`` queryparameter may be repeated. Each grouping is treated"},{"line_number":218,"context_line":"independently."},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Anti-affinity"},{"line_number":221,"context_line":"~~~~~~~~~~~~~"},{"line_number":222,"context_line":"There were discussions about supporting ``!`` syntax in ``same_subtree`` to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_49fb3646","line":219,"in_reply_to":"bfb3d3c7_32e2f0a1","updated":"2019-05-24 20:17:44.000000000","message":"\u003e Do we have an alternative subtree definition than [1] that\n \u003e clarifies these cases?\n\nYes, how\u0027s this:\n\nWe define \"same_subtree\" as \"all of the resource providers satisfying the request must be rooted at one of the resource providers satisfying the request\". Or put another way: \"one of the resource providers satisfying the request must be the direct ancestor of all the other resource providers satisfying the request\". So it\u0027s irrelevant that there may exist another ancestor common to all of them (and others) - because that ancestor isn\u0027t involved in satisfying the request. So for example:\n\n \u003e Are fpga1_0 fpga1_1 considered to be in the same subtree?\n\n*Only* if some other part of the request is satisfied by numa1 or compute_node.\n\nIf you can think of a term that conveys this meaning better than \"same subtree\" (and is still terse enough to be reasonable as a queryparam key) I\u0027m all ears.\n\nAlso note:\n- We definitely support scenarios where this definition degenerates to include the root node; so \u0027proper\u0027 would be incorrect.\n- Using \u0027proper\u0027 and defining that relative to the root node would force us to only support subtrees starting at the second level. Whereas the above definition allows us to support subtrees at any level.\n- Even if what we were doing *was* technically \"same proper subtree\" I would have argued that the intent was clear enough not to warrant the extra verbosity and confusion of including \u0027proper\u0027 in the name.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1dd32b1a7f0c0d1ec5aabde02938bcf55b0ad8f8","unresolved":false,"context_lines":[{"line_number":216,"context_line":""},{"line_number":217,"context_line":"The ``same_subtree`` queryparameter may be repeated. Each grouping is treated"},{"line_number":218,"context_line":"independently."},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Anti-affinity"},{"line_number":221,"context_line":"~~~~~~~~~~~~~"},{"line_number":222,"context_line":"There were discussions about supporting ``!`` syntax in ``same_subtree`` to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_d701ea07","line":219,"in_reply_to":"bfb3d3c7_49fb3646","updated":"2019-05-27 17:10:18.000000000","message":"Your definition works for me. Let\u0027s include the definition in the spec and later to the API doc.\n\nI still feel that we are a bit forcing our users to explicitly select the root of the subtree to have the definition work. But I have no better idea. Sorry for the noise. :)","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":216,"context_line":""},{"line_number":217,"context_line":"The ``same_subtree`` queryparameter may be repeated. Each grouping is treated"},{"line_number":218,"context_line":"independently."},{"line_number":219,"context_line":""},{"line_number":220,"context_line":"Anti-affinity"},{"line_number":221,"context_line":"~~~~~~~~~~~~~"},{"line_number":222,"context_line":"There were discussions about supporting ``!`` syntax in ``same_subtree`` to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2fa7bfa9","line":219,"in_reply_to":"bfb3d3c7_d701ea07","updated":"2019-05-28 17:28:21.000000000","message":"no i had this conversation with erric a few weeks ago to on a different sepc. i think its good to document the definion.\n\ni was initally leaing toward the propper_subtree definition too but i also think erric definition makes sense as it also works in the case wehre the tree consist of only the root node which is a nice property.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":222,"context_line":"There were discussions about supporting ``!`` syntax in ``same_subtree`` to"},{"line_number":223,"context_line":"express anti-affinity (e.g. ``same_subtree\u003d$X,!$Y`` meaning \"resources from"},{"line_number":224,"context_line":"group ``$Y`` shall *not* come from the same subtree as resources from group"},{"line_number":225,"context_line":"``$X``\"). This shall be deferred to a future release."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"resourceless request groups"},{"line_number":228,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_2d0055ab","line":225,"range":{"start_line":225,"start_character":24,"end_line":225,"end_character":32},"updated":"2019-05-24 13:42:04.000000000","message":"+1","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b96d7dcba0eb12dd8bac4ebdbc6785b5d7c5a848","unresolved":false,"context_lines":[{"line_number":222,"context_line":"There were discussions about supporting ``!`` syntax in ``same_subtree`` to"},{"line_number":223,"context_line":"express anti-affinity (e.g. ``same_subtree\u003d$X,!$Y`` meaning \"resources from"},{"line_number":224,"context_line":"group ``$Y`` shall *not* come from the same subtree as resources from group"},{"line_number":225,"context_line":"``$X``\"). This shall be deferred to a future release."},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"resourceless request groups"},{"line_number":228,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_6fca974e","line":225,"range":{"start_line":225,"start_character":24,"end_line":225,"end_character":32},"in_reply_to":"bfb3d3c7_2d0055ab","updated":"2019-05-28 17:28:21.000000000","message":"ok if we need that to do anti affintiy of nics for ha bonding  we can always do it in nova or whatever the clint is in a filter so i dont think we loose anything by punting this until later\n+1","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":230,"context_line":"identify a provider as a placeholder in the subtree structure even if I don\u0027t"},{"line_number":231,"context_line":"need any resources from that provider."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"It is currently a requirement that a ``resources$S`` exist for all ``$S`` in a"},{"line_number":234,"context_line":"request. This restriction shall be removed such that a request group may exist"},{"line_number":235,"context_line":"e.g. with only ``required$S``."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_0dda314b","line":233,"range":{"start_line":233,"start_character":66,"end_line":233,"end_character":73},"updated":"2019-05-24 13:42:04.000000000","message":"Even if $S is empty? or just if the $S is not empty? I.e. does the unsuffixed group always needs to request resources?","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1dd32b1a7f0c0d1ec5aabde02938bcf55b0ad8f8","unresolved":false,"context_lines":[{"line_number":230,"context_line":"identify a provider as a placeholder in the subtree structure even if I don\u0027t"},{"line_number":231,"context_line":"need any resources from that provider."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"It is currently a requirement that a ``resources$S`` exist for all ``$S`` in a"},{"line_number":234,"context_line":"request. This restriction shall be removed such that a request group may exist"},{"line_number":235,"context_line":"e.g. with only ``required$S``."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_5a0be122","line":233,"range":{"start_line":233,"start_character":66,"end_line":233,"end_character":73},"in_reply_to":"bfb3d3c7_09c0dee0","updated":"2019-05-27 17:10:18.000000000","message":"I don\u0027t know what I really wanted to ask. :/","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"c2e7a8102c0e8fbd928eedab326572029799e612","unresolved":false,"context_lines":[{"line_number":230,"context_line":"identify a provider as a placeholder in the subtree structure even if I don\u0027t"},{"line_number":231,"context_line":"need any resources from that provider."},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"It is currently a requirement that a ``resources$S`` exist for all ``$S`` in a"},{"line_number":234,"context_line":"request. This restriction shall be removed such that a request group may exist"},{"line_number":235,"context_line":"e.g. with only ``required$S``."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_09c0dee0","line":233,"range":{"start_line":233,"start_character":66,"end_line":233,"end_character":73},"in_reply_to":"bfb3d3c7_0dda314b","updated":"2019-05-24 20:17:44.000000000","message":"um, pretty sure it has to request resources.\n\n[Later] Yeah, we have an empty string check:\n\n\"Badly formed resources parameter. Expected resources query string parameter in form: ?resources\u003dVCPU:2,MEMORY_MB:1024. Got: empty string.\"\n\nIs it important that this be clarified here?","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1dd32b1a7f0c0d1ec5aabde02938bcf55b0ad8f8","unresolved":false,"context_lines":[{"line_number":232,"context_line":""},{"line_number":233,"context_line":"It is currently a requirement that a ``resources$S`` exist for all ``$S`` in a"},{"line_number":234,"context_line":"request. This restriction shall be removed such that a request group may exist"},{"line_number":235,"context_line":"e.g. with only ``required$S``."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"For example, given a model like::"},{"line_number":238,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_9a2e3990","line":235,"range":{"start_line":235,"start_character":0,"end_line":235,"end_character":29},"updated":"2019-05-27 17:10:18.000000000","message":"Will we support request group without resources$S and required$S but with only a member_of$S ? What about a single in_tree$S ?","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"95a078fafbdceaa5b31766d7938f3e0b79c6bb9f","unresolved":false,"context_lines":[{"line_number":232,"context_line":""},{"line_number":233,"context_line":"It is currently a requirement that a ``resources$S`` exist for all ``$S`` in a"},{"line_number":234,"context_line":"request. This restriction shall be removed such that a request group may exist"},{"line_number":235,"context_line":"e.g. with only ``required$S``."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"For example, given a model like::"},{"line_number":238,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_830a111d","line":235,"range":{"start_line":235,"start_character":0,"end_line":235,"end_character":29},"in_reply_to":"bfb3d3c7_0dee80b3","updated":"2019-05-30 22:38:26.000000000","message":"Chris addressed this in https://review.opendev.org/#/c/662191/","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"85aa65dde182604b6049584f1ac183c7b069ba65","unresolved":false,"context_lines":[{"line_number":232,"context_line":""},{"line_number":233,"context_line":"It is currently a requirement that a ``resources$S`` exist for all ``$S`` in a"},{"line_number":234,"context_line":"request. This restriction shall be removed such that a request group may exist"},{"line_number":235,"context_line":"e.g. with only ``required$S``."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"For example, given a model like::"},{"line_number":238,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_0dee80b3","line":235,"range":{"start_line":235,"start_character":0,"end_line":235,"end_character":29},"in_reply_to":"bfb3d3c7_9a2e3990","updated":"2019-05-29 20:10:17.000000000","message":"Yes, that\u0027s the point - but note that such a request would only make sense in the context of the other groups existing in the request, at least one of which requests actual resources.\n\nWe\u0027ve already said (in cdent\u0027s patch for this [1][2][3], though it would be worth reiterating here) that there must be resources *somewhere* in the request. So you can easily walk through the above and assign meaning to them:\n\n- Only member_of$S: If my host is in a \"host aggregate\", and we\u0027ve implemented that by putting *only* the root provider in (the placement mirror of) the aggregate (which makes sense when services other than nova can own parts of the tree) and we\u0027re asking for resources from somewhere other than the root (e.g. proc/mem from NUMA nodes; or VFs from NICs).\n- Only in_tree$S: I want to add a VF to an existing VM. I know the host UUID, which is the root provider UUID, but don\u0027t care which device (child provider) the VF comes from.\n\n[1] https://review.opendev.org/#/c/657510/5//COMMIT_MSG@21\n[2] https://review.opendev.org/#/c/657510/5/placement/lib.py@118\n[3] https://review.opendev.org/#/c/657510/5/placement/tests/unit/test_util.py@911","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"135745e7573a83c963c82fd73d4d064c59196167","unresolved":false,"context_lines":[{"line_number":262,"context_line":" \u0026resources_VIF_NET2\u003dVF:1"},{"line_number":263,"context_line":" \u0026required_VIF_NET2\u003dNET2"},{"line_number":264,"context_line":" # NOTE: there is no resources_NIC_AFFINITY"},{"line_number":265,"context_line":" \u0026required_NIC_AFFINITY\u003dHW_NIC_ROOT"},{"line_number":266,"context_line":" \u0026same_subtree\u003d_VIF_NET1,_VIF_NET2,_NIC_AFFINITY"},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"The returned candidates will include::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_477b13f4","line":265,"range":{"start_line":265,"start_character":0,"end_line":265,"end_character":35},"updated":"2019-05-27 07:42:02.000000000","message":"we already have same_subtree, why we still need this HW_NIC_ROOT trait","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"85aa65dde182604b6049584f1ac183c7b069ba65","unresolved":false,"context_lines":[{"line_number":262,"context_line":" \u0026resources_VIF_NET2\u003dVF:1"},{"line_number":263,"context_line":" \u0026required_VIF_NET2\u003dNET2"},{"line_number":264,"context_line":" # NOTE: there is no resources_NIC_AFFINITY"},{"line_number":265,"context_line":" \u0026required_NIC_AFFINITY\u003dHW_NIC_ROOT"},{"line_number":266,"context_line":" \u0026same_subtree\u003d_VIF_NET1,_VIF_NET2,_NIC_AFFINITY"},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"The returned candidates will include::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_ed1e8cb9","line":265,"range":{"start_line":265,"start_character":0,"end_line":265,"end_character":35},"in_reply_to":"bfb3d3c7_477b13f4","updated":"2019-05-29 20:10:17.000000000","message":"\u003e we already have same_subtree, why we still need this HW_NIC_ROOT\n \u003e trait\n\nBecause we aren\u0027t requesting resources from the NIC itself, so we have to have some kind of handle to tie the subtree together.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1dd32b1a7f0c0d1ec5aabde02938bcf55b0ad8f8","unresolved":false,"context_lines":[{"line_number":262,"context_line":" \u0026resources_VIF_NET2\u003dVF:1"},{"line_number":263,"context_line":" \u0026required_VIF_NET2\u003dNET2"},{"line_number":264,"context_line":" # NOTE: there is no resources_NIC_AFFINITY"},{"line_number":265,"context_line":" \u0026required_NIC_AFFINITY\u003dHW_NIC_ROOT"},{"line_number":266,"context_line":" \u0026same_subtree\u003d_VIF_NET1,_VIF_NET2,_NIC_AFFINITY"},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"The returned candidates will include::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_3a54edfd","line":265,"range":{"start_line":265,"start_character":0,"end_line":265,"end_character":35},"in_reply_to":"bfb3d3c7_477b13f4","updated":"2019-05-27 17:10:18.000000000","message":"This is exactly the part of the definition of the same_subtree that feels artificial and forced to me. But as I wrote above (L219) I don\u0027t have a better solution to select the root of the subtree. :/","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"5b4a1a3a1c4ac9817f683b11a61e78f9d09fbbdd","unresolved":false,"context_lines":[{"line_number":360,"context_line":""},{"line_number":361,"context_line":"Performance Impact"},{"line_number":362,"context_line":"------------------"},{"line_number":363,"context_line":"It is expected that ``can_split`` will add a nontrivial burden to both the"},{"line_number":364,"context_line":"database queries for providers with available resource and the python"},{"line_number":365,"context_line":"processing of their results. Certainly this impact should be constrained to"},{"line_number":366,"context_line":"queries that use ``can_split``; we should strive to further constrain it only"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_3ab38d0c","line":363,"updated":"2019-05-27 17:52:59.000000000","message":"Yeah, and that\u0027s a problem because I suspect most clouds have NUMA hosts but don\u0027t run NUMA guests, so can_split will be used *a lot*. I don\u0027t have a solution, but it\u0027s a thing :(","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"6867bf9003c5545cd65c0eec5479bd83ac03da18","unresolved":false,"context_lines":[{"line_number":360,"context_line":""},{"line_number":361,"context_line":"Performance Impact"},{"line_number":362,"context_line":"------------------"},{"line_number":363,"context_line":"It is expected that ``can_split`` will add a nontrivial burden to both the"},{"line_number":364,"context_line":"database queries for providers with available resource and the python"},{"line_number":365,"context_line":"processing of their results. Certainly this impact should be constrained to"},{"line_number":366,"context_line":"queries that use ``can_split``; we should strive to further constrain it only"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_d13faf22","line":363,"in_reply_to":"bfb3d3c7_3ab38d0c","updated":"2019-05-28 10:19:34.000000000","message":"I\u0027m increasingly feeling like we\u0027re trying to fix a problem in placement that ought to be fixed in nova-compute.\n\nIf a cloud has \"NUMA hosts but [doesn\u0027t] run NUMA guests\" then maybe those hosts shouldn\u0027t be reporting NUMA inventory?\n\nAnd if they don\u0027t report NUMA inventory, then we don\u0027t need can_split.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":8768,"name":"Chris Friesen","email":"chris.friesen@windriver.com","username":"cbf123"},"change_message_id":"c961042bc4c0ae953f94484f1d7990f8481436be","unresolved":false,"context_lines":[{"line_number":360,"context_line":""},{"line_number":361,"context_line":"Performance Impact"},{"line_number":362,"context_line":"------------------"},{"line_number":363,"context_line":"It is expected that ``can_split`` will add a nontrivial burden to both the"},{"line_number":364,"context_line":"database queries for providers with available resource and the python"},{"line_number":365,"context_line":"processing of their results. Certainly this impact should be constrained to"},{"line_number":366,"context_line":"queries that use ``can_split``; we should strive to further constrain it only"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_8f7b4b79","line":363,"in_reply_to":"bfb3d3c7_6f637e43","updated":"2019-05-28 16:55:56.000000000","message":"\u003e Also, as Alex just said,\n \u003e can_split gives us the ability to mix NUMA and non-NUMA on the same\n \u003e host (is that a thing operators want though?)\n\nActually, there is currently a problem with mixing NUMA and non-NUMA on the same host if they\u0027re using 4K memory pages.  The non-NUMA guests can allocate memory from whatever NUMA node they happen to be running on when they allocate memory, making it fundamentally impossible to properly account for 4K memory on a per-NUMA-node basis.\n\nOne possible fix would be to make 4K pages not strictly NUMA-affined, so that they could be allocated from another NUMA node if there aren\u0027t any available on the \"correct\" node.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"e172ecb46ef0538c0b7b4d59d34285f10afc9f96","unresolved":false,"context_lines":[{"line_number":360,"context_line":""},{"line_number":361,"context_line":"Performance Impact"},{"line_number":362,"context_line":"------------------"},{"line_number":363,"context_line":"It is expected that ``can_split`` will add a nontrivial burden to both the"},{"line_number":364,"context_line":"database queries for providers with available resource and the python"},{"line_number":365,"context_line":"processing of their results. Certainly this impact should be constrained to"},{"line_number":366,"context_line":"queries that use ``can_split``; we should strive to further constrain it only"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_cf538a38","line":363,"in_reply_to":"bfb3d3c7_6f637e43","updated":"2019-05-28 12:28:32.000000000","message":"\u003e Also, as Alex just said,\n \u003e can_split gives us the ability to mix NUMA and non-NUMA on the same\n \u003e host (is that a thing operators want though?)\n\nRight. We keep sticking \"is that a thing operators want\" into parentheses but it\u0027s the most important question.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9b0b29070c6515c10bea0686087c2c6a414cf6af","unresolved":false,"context_lines":[{"line_number":360,"context_line":""},{"line_number":361,"context_line":"Performance Impact"},{"line_number":362,"context_line":"------------------"},{"line_number":363,"context_line":"It is expected that ``can_split`` will add a nontrivial burden to both the"},{"line_number":364,"context_line":"database queries for providers with available resource and the python"},{"line_number":365,"context_line":"processing of their results. Certainly this impact should be constrained to"},{"line_number":366,"context_line":"queries that use ``can_split``; we should strive to further constrain it only"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_891b39c8","line":363,"in_reply_to":"bfb3d3c7_8f7b4b79","updated":"2019-05-29 13:04:38.000000000","message":"there are a number of ways to fix that on the nova side.\n\nwe coudld numa affine the 4k pages on the host but not expose that to the guest so it can change if we do live migration without the guest needing to be aware. so its not fundementally impossable to account for 4k pages at the numa level we just need to use all the tools that we are given.\ne.g. use the memory device element in libvirt to allocate the guest memroy even for non numa guests form specific host numa nodes and ignore affinty(we could do soft affinity with a weigher) since the guest did not ask for it.\n\ntaking a different tack we could initially report memory_mb and vCPUs at the compute node level and only report pCPUs at the numa level. if we do that we dont need can_split but also dont get numa affinity between  meory and pCPUs enforce by placment, the numa toplogy filter will still have to do that.\n\nall pinned guest have a numa toplogy so they will always work this way. if we report hugepages to placement per numa node that will cover most of the cases too since hugepages today make the the guest a numa guest. as such for pinned guest with hugepages placemnet would actully do the affinity for us.\n\nso im not actully sure when ^ does not work.\n\nthe only case i can think of is if you explictly set hw:mem_page_size\u003dsmall or hw:mem_page_size\u003d4k + hw:cpu_policy\u003ddedicated.\n\nin that case the guest has a numa topology but the ram would be allocated from the compute RP not the numa node but since you have set hw:cpu_policy dedicated we woudl normally try to request both pCPUs and memory_mb in the same request group but we can special case this in the prefilter that doe the transformation to just not do that.\n\nso im not actully sure we need can_split if we always report \nvcpus and memory_mb(4k memory only) on the compute node RP and report hugepages and PCPUs allways on the numa nodes.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"e5bb8df1b299aad8fcbb5c8ae65409b6b8ee88c2","unresolved":false,"context_lines":[{"line_number":360,"context_line":""},{"line_number":361,"context_line":"Performance Impact"},{"line_number":362,"context_line":"------------------"},{"line_number":363,"context_line":"It is expected that ``can_split`` will add a nontrivial burden to both the"},{"line_number":364,"context_line":"database queries for providers with available resource and the python"},{"line_number":365,"context_line":"processing of their results. Certainly this impact should be constrained to"},{"line_number":366,"context_line":"queries that use ``can_split``; we should strive to further constrain it only"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_6f637e43","line":363,"in_reply_to":"bfb3d3c7_d13faf22","updated":"2019-05-28 12:16:42.000000000","message":"\u003e I\u0027m increasingly feeling like we\u0027re trying to fix a problem in\n \u003e placement that ought to be fixed in nova-compute.\n \u003e \n \u003e If a cloud has \"NUMA hosts but [doesn\u0027t] run NUMA guests\" then\n \u003e maybe those hosts shouldn\u0027t be reporting NUMA inventory?\n \u003e \n \u003e And if they don\u0027t report NUMA inventory, then we don\u0027t need\n \u003e can_split.\n\nI\u0027ve brought this up here and there, I don\u0027t recall a specific argument against it (doesn\u0027t mean there isn\u0027t one). Upgradeability is a concern, as is the fact that currently in Nova we abuse the InstanceNUMATopology to include things that aren\u0027t really NUMA, like CPU pinning and hugepages. Untangling all that would be a lot of work in Nova, but it\u0027s feasible. Also, as Alex just said, can_split gives us the ability to mix NUMA and non-NUMA on the same host (is that a thing operators want though?)","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"change_message_id":"c5183e394d3ecfa0884670ba213ca74b9d7944c7","unresolved":false,"context_lines":[{"line_number":360,"context_line":""},{"line_number":361,"context_line":"Performance Impact"},{"line_number":362,"context_line":"------------------"},{"line_number":363,"context_line":"It is expected that ``can_split`` will add a nontrivial burden to both the"},{"line_number":364,"context_line":"database queries for providers with available resource and the python"},{"line_number":365,"context_line":"processing of their results. Certainly this impact should be constrained to"},{"line_number":366,"context_line":"queries that use ``can_split``; we should strive to further constrain it only"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_6f15be9b","line":363,"in_reply_to":"bfb3d3c7_d13faf22","updated":"2019-05-28 12:13:53.000000000","message":"\u003e If a cloud has \"NUMA hosts but [doesn\u0027t] run NUMA guests\" then\n \u003e maybe those hosts shouldn\u0027t be reporting NUMA inventory?\n\nEmm...I thought the can_split is for the case of mixing NUMA instance and non-NUMA instance on the same host, not just running non-NUMA instance on NUMA host.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"4f91f5fb11ace50c81ccce03a05bc8f2a0b6c4ce","unresolved":false,"context_lines":[{"line_number":367,"context_line":"to environments where it could possibly be relevant. For example, if there were"},{"line_number":368,"context_line":"a fast way to predetermine that there exist no trees where the resource classes"},{"line_number":369,"context_line":"under ``can_split`` are provided by more than one provider, we could bypass the"},{"line_number":370,"context_line":"remainder of the ``can_split`` algorithm entirely."},{"line_number":371,"context_line":""},{"line_number":372,"context_line":"The work for ``same_subtree`` will probably (at least initially) be done on the"},{"line_number":373,"context_line":"python side as additional filtering under ``_merge_candidates``. This could"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_b34c9842","line":370,"updated":"2019-05-25 09:32:52.000000000","message":"Right. As noted above, since I still don\u0027t get the use case of this, I\u0027m not sure what we will get from \"can_split\" warrants the the cost to get in and maintain the new feature.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"4f91f5fb11ace50c81ccce03a05bc8f2a0b6c4ce","unresolved":false,"context_lines":[{"line_number":372,"context_line":"The work for ``same_subtree`` will probably (at least initially) be done on the"},{"line_number":373,"context_line":"python side as additional filtering under ``_merge_candidates``. This could"},{"line_number":374,"context_line":"have some performance impact especially on large data sets. Again, we should"},{"line_number":375,"context_line":"optimize requests without ``same_subtree``, where ``same_subtree`` refers to"},{"line_number":376,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":377,"context_line":""},{"line_number":378,"context_line":"Resourceless request groups may add a small additional burden to database"},{"line_number":379,"context_line":"queries, but it should be negligible, especially since it should be relatively"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_7352a0e0","line":376,"range":{"start_line":375,"start_character":50,"end_line":376,"end_character":14},"updated":"2019-05-25 09:32:52.000000000","message":"Is there a case where the same subtree refers to an unnumbered/unsuffixed/non-granular request?","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"b9ae64f4bf9a172944f75d839f6f128d2281e6fa","unresolved":false,"context_lines":[{"line_number":372,"context_line":"The work for ``same_subtree`` will probably (at least initially) be done on the"},{"line_number":373,"context_line":"python side as additional filtering under ``_merge_candidates``. This could"},{"line_number":374,"context_line":"have some performance impact especially on large data sets. Again, we should"},{"line_number":375,"context_line":"optimize requests without ``same_subtree``, where ``same_subtree`` refers to"},{"line_number":376,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":377,"context_line":""},{"line_number":378,"context_line":"Resourceless request groups may add a small additional burden to database"},{"line_number":379,"context_line":"queries, but it should be negligible, especially since it should be relatively"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_93f87449","line":376,"range":{"start_line":375,"start_character":50,"end_line":376,"end_character":14},"in_reply_to":"bfb3d3c7_7352a0e0","updated":"2019-05-25 13:45:00.000000000","message":"No. If you need to affine resources, they have to be requested in granular groups. Do you see a case where that limitation will be a problem?","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"ab67614d8a174f510a935f7f46dc8160bff604ef","unresolved":false,"context_lines":[{"line_number":372,"context_line":"The work for ``same_subtree`` will probably (at least initially) be done on the"},{"line_number":373,"context_line":"python side as additional filtering under ``_merge_candidates``. This could"},{"line_number":374,"context_line":"have some performance impact especially on large data sets. Again, we should"},{"line_number":375,"context_line":"optimize requests without ``same_subtree``, where ``same_subtree`` refers to"},{"line_number":376,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":377,"context_line":""},{"line_number":378,"context_line":"Resourceless request groups may add a small additional burden to database"},{"line_number":379,"context_line":"queries, but it should be negligible, especially since it should be relatively"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_99fad5ba","line":376,"range":{"start_line":375,"start_character":50,"end_line":376,"end_character":14},"in_reply_to":"bfb3d3c7_93f87449","updated":"2019-05-26 06:41:58.000000000","message":"\u003e Do you see a case where that limitation will be a\n \u003e problem?\n\nNope. Just to make sure.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fe0ea04a43cfc5b69354cde7014daae04803d066","unresolved":false,"context_lines":[{"line_number":376,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":377,"context_line":""},{"line_number":378,"context_line":"Resourceless request groups may add a small additional burden to database"},{"line_number":379,"context_line":"queries, but it should be negligible, especially since it should be relatively"},{"line_number":380,"context_line":"rare in the wild. However, in this case we may not be able to optimize."},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"Documentation Impact"},{"line_number":383,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_6ddc0de4","line":380,"range":{"start_line":379,"start_character":38,"end_line":380,"end_character":17},"updated":"2019-05-24 13:42:04.000000000","message":"Just a not that it might not that rare. If two leaf RPs needs to be affined then  there will be a need to select a third RP that is a common ancestor of the two leaf RPs with a same_subtree query param. That common ancestor RP will be selected by a required trait, at least all of our current examples do this.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"c2e7a8102c0e8fbd928eedab326572029799e612","unresolved":false,"context_lines":[{"line_number":376,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":377,"context_line":""},{"line_number":378,"context_line":"Resourceless request groups may add a small additional burden to database"},{"line_number":379,"context_line":"queries, but it should be negligible, especially since it should be relatively"},{"line_number":380,"context_line":"rare in the wild. However, in this case we may not be able to optimize."},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"Documentation Impact"},{"line_number":383,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_a97512cd","line":380,"range":{"start_line":379,"start_character":38,"end_line":380,"end_character":17},"in_reply_to":"bfb3d3c7_6ddc0de4","updated":"2019-05-24 20:17:44.000000000","message":"Yes, but it will be rare for that ancestor to not be providing resources, right? The common case is where we want devices affined to the NUMA node providing VCPU and MEMORY_MB.\n\nWhen we get to future use cases where we want to add devices to an existing VM and affine them to wherever the VM\u0027s VCPU and MEMORY_MB already are, we\u0027ll need extra features (in_subtree\u003d$rp_uuid) to satisfy that anyway.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"1dd32b1a7f0c0d1ec5aabde02938bcf55b0ad8f8","unresolved":false,"context_lines":[{"line_number":376,"context_line":"only one group, where no nested providers exist in the database, etc."},{"line_number":377,"context_line":""},{"line_number":378,"context_line":"Resourceless request groups may add a small additional burden to database"},{"line_number":379,"context_line":"queries, but it should be negligible, especially since it should be relatively"},{"line_number":380,"context_line":"rare in the wild. However, in this case we may not be able to optimize."},{"line_number":381,"context_line":""},{"line_number":382,"context_line":"Documentation Impact"},{"line_number":383,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"bfb3d3c7_7a77c5a1","line":380,"range":{"start_line":379,"start_character":38,"end_line":380,"end_character":17},"in_reply_to":"bfb3d3c7_a97512cd","updated":"2019-05-27 17:10:18.000000000","message":"Good point. In our current realty NUMA PR will be the root of the affinity and that RP will provide some resource as well.","commit_id":"4303de15ad8d106927ae958623cc7bf49ed6e60f"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"63d0415eb5f332c1f89ffa7154c90df03525313b","unresolved":false,"context_lines":[{"line_number":26,"context_line":"Proposed change"},{"line_number":27,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"All changes are to the ``GET /allocation_candidates`` operation via new"},{"line_number":30,"context_line":"microversions, as described below."},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"can_split"},{"line_number":33,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bfb3d3c7_c389e974","line":30,"range":{"start_line":29,"start_character":0,"end_line":30,"end_character":34},"updated":"2019-05-30 22:46:03.000000000","message":"Should this sentence be singularized in this new context?","commit_id":"92a96f8b341f4e4cb1e80e12a6fcaec8328f1fd3"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"800f3d4a67a824661361f0161f8fd65045cb38fc","unresolved":false,"context_lines":[{"line_number":26,"context_line":"Proposed change"},{"line_number":27,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"All changes are to the ``GET /allocation_candidates`` operation via new"},{"line_number":30,"context_line":"microversions, as described below."},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"can_split"},{"line_number":33,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_c2e1bad2","line":30,"range":{"start_line":29,"start_character":0,"end_line":30,"end_character":34},"in_reply_to":"bfb3d3c7_c389e974","updated":"2019-06-03 10:29:38.000000000","message":"prolly, but if there are no further responses to the email thread about this, we might just be able to abandon this to the future","commit_id":"92a96f8b341f4e4cb1e80e12a6fcaec8328f1fd3"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"63d0415eb5f332c1f89ffa7154c90df03525313b","unresolved":false,"context_lines":[{"line_number":96,"context_line":"          as the operating system prefers. If ``can_split`` is used, then in"},{"line_number":97,"context_line":"          order for placement to have an accurate representation of reality in"},{"line_number":98,"context_line":"          its allocations, it would be necessary to pin the workload\u0027s VCPUs to"},{"line_number":99,"context_line":"          where they were initially placed. This would require change in Nova."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Candidate Explosion"},{"line_number":102,"context_line":"~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bfb3d3c7_23b1e547","line":99,"updated":"2019-05-30 22:46:03.000000000","message":"unless we do the thing where we leave the VCPUs on the root RP etc","commit_id":"92a96f8b341f4e4cb1e80e12a6fcaec8328f1fd3"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"800f3d4a67a824661361f0161f8fd65045cb38fc","unresolved":false,"context_lines":[{"line_number":96,"context_line":"          as the operating system prefers. If ``can_split`` is used, then in"},{"line_number":97,"context_line":"          order for placement to have an accurate representation of reality in"},{"line_number":98,"context_line":"          its allocations, it would be necessary to pin the workload\u0027s VCPUs to"},{"line_number":99,"context_line":"          where they were initially placed. This would require change in Nova."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Candidate Explosion"},{"line_number":102,"context_line":"~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fb8cfa7_42cdca5b","line":99,"in_reply_to":"bfb3d3c7_23b1e547","updated":"2019-06-03 10:29:38.000000000","message":"right, but then we\u0027re obviating the primary purpose of can_split,","commit_id":"92a96f8b341f4e4cb1e80e12a6fcaec8328f1fd3"}]}