)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4965847fcc9435826d5e595458f0d7bd60decfcc","unresolved":false,"context_lines":[{"line_number":21,"context_line":"but not CN1. In the second case we also request resources from CN1"},{"line_number":22,"context_line":"besides requesting resources from SS1 and SS2."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"The first case had been broken before nested providers are supported."},{"line_number":25,"context_line":"But this is fixed now thanks to the following commit, which enables"},{"line_number":26,"context_line":"getting nested providers as well as sharing providers."},{"line_number":27,"context_line":"patch: https://review.openstack.org/#/c/567508/"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":24,"id":"5f7c97a3_7b8dee33","line":24,"range":{"start_line":24,"start_character":0,"end_line":24,"end_character":69},"updated":"2018-06-28 22:23:35.000000000","message":"Broken how? In that CN1 was also returned even though only resources from SS1 and SS2 were requested?","commit_id":"042bc07fd87f3649929ab00429ba369f5378f07e"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0d79cd27de8cf564166f002daeb17a2dc6a82008","unresolved":false,"context_lines":[{"line_number":21,"context_line":"but not CN1. In the second case we also request resources from CN1"},{"line_number":22,"context_line":"besides requesting resources from SS1 and SS2."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"The first case had been broken before nested providers are supported."},{"line_number":25,"context_line":"But this is fixed now thanks to the following commit, which enables"},{"line_number":26,"context_line":"getting nested providers as well as sharing providers."},{"line_number":27,"context_line":"patch: https://review.openstack.org/#/c/567508/"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":24,"id":"5f7c97a3_bb99466e","line":24,"range":{"start_line":24,"start_character":0,"end_line":24,"end_character":69},"in_reply_to":"5f7c97a3_7b8dee33","updated":"2018-06-28 22:26:42.000000000","message":"No, no candidates were returned.  We didn\u0027t have the concept of \"anchoring\" a request on a non-sharing provider in an aggregate.  (It\u0027s in the bug report, but yeah, could\u0027ve stood to be mentioned here.)","commit_id":"042bc07fd87f3649929ab00429ba369f5378f07e"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"a3ca03793feef0a298aa66d0f718c445cb52940f","unresolved":false,"context_lines":[{"line_number":21,"context_line":"but not CN1. In the second case we also request resources from CN1"},{"line_number":22,"context_line":"besides requesting resources from SS1 and SS2."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"The first case had been broken before nested providers are supported."},{"line_number":25,"context_line":"But this is fixed now thanks to the following commit, which enables"},{"line_number":26,"context_line":"getting nested providers as well as sharing providers."},{"line_number":27,"context_line":"patch: https://review.openstack.org/#/c/567508/"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":24,"id":"5f7c97a3_fbb81ec8","line":24,"range":{"start_line":24,"start_character":0,"end_line":24,"end_character":69},"in_reply_to":"5f7c97a3_bb99466e","updated":"2018-06-28 22:27:27.000000000","message":"Cool, thanks.","commit_id":"042bc07fd87f3649929ab00429ba369f5378f07e"}],"nova/tests/functional/api/openstack/placement/db/test_allocation_candidates.py":[{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"405532a734a4e9b9a059f1f2012b0f025104e58c","unresolved":false,"context_lines":[{"line_number":1784,"context_line":"        ]"},{"line_number":1785,"context_line":"        self._validate_allocation_requests(expected, alloc_cands)"},{"line_number":1786,"context_line":""},{"line_number":1787,"context_line":"        expected \u003d {"},{"line_number":1788,"context_line":"            \u0027ss1\u0027: set(["},{"line_number":1789,"context_line":"                (fields.ResourceClass.DISK_GB, 1600, 0),"},{"line_number":1790,"context_line":"            ]),"},{"line_number":1791,"context_line":"            \u0027ss2\u0027: set(["},{"line_number":1792,"context_line":"                (fields.ResourceClass.IPV4_ADDRESS, 24, 0),"},{"line_number":1793,"context_line":"                (fields.ResourceClass.SRIOV_NET_VF, 16, 0),"},{"line_number":1794,"context_line":"            ]),"},{"line_number":1795,"context_line":"        }"},{"line_number":1796,"context_line":"        self._validate_provider_summary_resources(expected, alloc_cands)"},{"line_number":1797,"context_line":""},{"line_number":1798,"context_line":"    def test_two_sharing_indirectly_connected_connecting_gives_resource(self):"},{"line_number":1799,"context_line":"        # This covers the following setup"}],"source_content_type":"text/x-python","patch_set":22,"id":"5f7c97a3_594e0739","line":1796,"range":{"start_line":1787,"start_character":0,"end_line":1796,"end_character":72},"updated":"2018-06-15 20:06:46.000000000","message":"This will bounce once [1] lands (we\u0027ll get cn1 as well).  But for the moment, it should be cool.\n\n[1] https://review.openstack.org/#/c/559480/","commit_id":"1a2362d8fca8c35235d8c3a02946a4120c3872b9"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"405532a734a4e9b9a059f1f2012b0f025104e58c","unresolved":false,"context_lines":[{"line_number":1806,"context_line":"        #                 SRIOV_NET_VF)"},{"line_number":1807,"context_line":"        # The request then made for resources from all three RPs"},{"line_number":1808,"context_line":""},{"line_number":1809,"context_line":"        ss1 \u003d self._create_provider(\u0027ss1\u0027, uuids.agg1)"},{"line_number":1810,"context_line":"        tb.set_traits(ss1, \"MISC_SHARES_VIA_AGGREGATE\")"},{"line_number":1811,"context_line":"        tb.add_inventory(ss1, fields.ResourceClass.DISK_GB, 1600)"},{"line_number":1812,"context_line":""},{"line_number":1813,"context_line":"        cn1 \u003d self._create_provider(\u0027cn1\u0027, uuids.agg1, uuids.agg2)"},{"line_number":1814,"context_line":"        tb.add_inventory(cn1, fields.ResourceClass.VCPU, 24)"},{"line_number":1815,"context_line":"        tb.add_inventory(cn1, fields.ResourceClass.MEMORY_MB, 2048)"},{"line_number":1816,"context_line":""},{"line_number":1817,"context_line":"        ss2 \u003d self._create_provider(\u0027ss2\u0027, uuids.agg2)"},{"line_number":1818,"context_line":"        tb.set_traits(ss2, \"MISC_SHARES_VIA_AGGREGATE\")"},{"line_number":1819,"context_line":"        tb.add_inventory(ss2, fields.ResourceClass.IPV4_ADDRESS, 24)"},{"line_number":1820,"context_line":"        tb.add_inventory(ss2, fields.ResourceClass.SRIOV_NET_VF, 16)"},{"line_number":1821,"context_line":""},{"line_number":1822,"context_line":"        alloc_cands \u003d self._get_allocation_candidates("},{"line_number":1823,"context_line":"            {\u0027\u0027: placement_lib.RequestGroup("}],"source_content_type":"text/x-python","patch_set":22,"id":"5f7c97a3_19072fcc","line":1820,"range":{"start_line":1809,"start_character":0,"end_line":1820,"end_character":68},"updated":"2018-06-15 20:06:46.000000000","message":"Same as above, yes?  Could be factored out into a common helper.","commit_id":"1a2362d8fca8c35235d8c3a02946a4120c3872b9"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e726bc55ff51f566ad5b5967a32429cd126c8b2f","unresolved":false,"context_lines":[{"line_number":1768,"context_line":""},{"line_number":1769,"context_line":"        alloc_cands \u003d self._get_allocation_candidates("},{"line_number":1770,"context_line":"            {\u0027\u0027: placement_lib.RequestGroup("},{"line_number":1771,"context_line":"                use_same_provider\u003dFalse,"},{"line_number":1772,"context_line":"                resources\u003d{"},{"line_number":1773,"context_line":"                    \u0027IPV4_ADDRESS\u0027: 2,"},{"line_number":1774,"context_line":"                    \u0027SRIOV_NET_VF\u0027: 1,"}],"source_content_type":"text/x-python","patch_set":24,"id":"5f7c97a3_3b70d640","line":1771,"range":{"start_line":1771,"start_character":34,"end_line":1771,"end_character":39},"updated":"2018-06-28 22:25:49.000000000","message":"OK and if this were True we wouldn\u0027t get anything back right?","commit_id":"042bc07fd87f3649929ab00429ba369f5378f07e"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"eac8b65a071e74fee963b6df767fb324c6748631","unresolved":false,"context_lines":[{"line_number":1768,"context_line":""},{"line_number":1769,"context_line":"        alloc_cands \u003d self._get_allocation_candidates("},{"line_number":1770,"context_line":"            {\u0027\u0027: placement_lib.RequestGroup("},{"line_number":1771,"context_line":"                use_same_provider\u003dFalse,"},{"line_number":1772,"context_line":"                resources\u003d{"},{"line_number":1773,"context_line":"                    \u0027IPV4_ADDRESS\u0027: 2,"},{"line_number":1774,"context_line":"                    \u0027SRIOV_NET_VF\u0027: 1,"}],"source_content_type":"text/x-python","patch_set":24,"id":"5f7c97a3_5bc7d247","line":1771,"range":{"start_line":1771,"start_character":34,"end_line":1771,"end_character":39},"in_reply_to":"5f7c97a3_3b70d640","updated":"2018-06-28 22:28:28.000000000","message":"Correct, because there\u0027s no single provider that can handle all three of these RCs.","commit_id":"042bc07fd87f3649929ab00429ba369f5378f07e"}],"nova/tests/functional/db/test_allocation_candidates.py":[{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"879c0e81d6dc873740d165c952505dfb83343716","unresolved":false,"context_lines":[{"line_number":1570,"context_line":"        # provider that aggregates the resources coming from ss1 and ss2 into a"},{"line_number":1571,"context_line":"        # single point. This problem reported in bug 1732731"},{"line_number":1572,"context_line":"        #"},{"line_number":1573,"context_line":"        # However today there is no way to express that we need"},{"line_number":1574,"context_line":"        # cn1 as a connection point but we allocate nothing from cn1."},{"line_number":1575,"context_line":"        # expected \u003d ["},{"line_number":1576,"context_line":"        #     [(\u0027cn1\u0027, \u003cnothing\u003e)"},{"line_number":1577,"context_line":"        #      (\u0027ss1\u0027, fields.ResourceClass.DISK_GB, 1500),"},{"line_number":1578,"context_line":"        #      (\u0027ss2\u0027, fields.ResourceClass.IPV4_ADDRESS, 2),"},{"line_number":1579,"context_line":"        #      (\u0027ss2\u0027, fields.ResourceClass.SRIOV_NET_VF, 1)],"},{"line_number":1580,"context_line":"        # ]"},{"line_number":1581,"context_line":"        # But we get nothing"},{"line_number":1582,"context_line":"        expected \u003d ["},{"line_number":1583,"context_line":"        ]"}],"source_content_type":"text/x-python","patch_set":9,"id":"7f96bb07_20ee2288","line":1580,"range":{"start_line":1573,"start_character":0,"end_line":1580,"end_character":11},"updated":"2018-01-15 09:08:25.000000000","message":"I\u0027m trying to debug this in https://review.openstack.org/#/c/533437/1, and this may need treating as a special case, which means this is a good opportunity to review the grand design again to see what is the real problem here.\n\nHere, we don\u0027t claim any resources from compute nodes. We actually get resources only from ss1 and ss2. However, since these two rps are in different aggregates, this may sound like creating a new bug that the API returns a combination from the different aggregates?\n\n\nLet\u0027s say \"the new bug would be a problem so we don\u0027t need to fix this\"; is it okay in the first place to return an allocation candidates across multiple aggregates? (this is how the bug https://bugs.launchpad.net/nova/+bug/1732707 is fixed in https://review.openstack.org/#/c/522407/)\n\n\nLet\u0027s say \"the new bug wouldn\u0027t be a problem so we need this bug fixed\"; should the compute nodes be in allocation candidates?\n\nIf yes, how about the case that, for example, 10 compute nodes and one shared storage are in the same aggregate, and request just 100 GB disk? Does placement API return all the following set?\n\n  [\n    [(cn1, \u003cnothing\u003e), (ss1, 100GB)]\n    [(cn2, \u003cnothing\u003e), (ss1, 100GB)]\n                   :\n    [(cn10, \u003cnothing\u003e), (ss1, 100GB)]\n    [(ss1, 100GB)]\n  ]\n\nIf no, even if the compute node is listed in provider summaries, how one can know which compute node is \"the relay point\" for which sharing providers? Or, is there no need for that associate information? Or even no need to list that \"relay point\" in provider summaries?","commit_id":"a9b0da7c9f9b93bc311f5ecf8737a47e1a7fd214"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"12d4f26e11ef4dc55ff6b7dc8554c9ca01f49d61","unresolved":false,"context_lines":[{"line_number":1570,"context_line":"        # provider that aggregates the resources coming from ss1 and ss2 into a"},{"line_number":1571,"context_line":"        # single point. This problem reported in bug 1732731"},{"line_number":1572,"context_line":"        #"},{"line_number":1573,"context_line":"        # However today there is no way to express that we need"},{"line_number":1574,"context_line":"        # cn1 as a connection point but we allocate nothing from cn1."},{"line_number":1575,"context_line":"        # expected \u003d ["},{"line_number":1576,"context_line":"        #     [(\u0027cn1\u0027, \u003cnothing\u003e)"},{"line_number":1577,"context_line":"        #      (\u0027ss1\u0027, fields.ResourceClass.DISK_GB, 1500),"},{"line_number":1578,"context_line":"        #      (\u0027ss2\u0027, fields.ResourceClass.IPV4_ADDRESS, 2),"},{"line_number":1579,"context_line":"        #      (\u0027ss2\u0027, fields.ResourceClass.SRIOV_NET_VF, 1)],"},{"line_number":1580,"context_line":"        # ]"},{"line_number":1581,"context_line":"        # But we get nothing"},{"line_number":1582,"context_line":"        expected \u003d ["},{"line_number":1583,"context_line":"        ]"}],"source_content_type":"text/x-python","patch_set":9,"id":"7f96bb07_f91ab76c","line":1580,"range":{"start_line":1573,"start_character":0,"end_line":1580,"end_character":11},"in_reply_to":"7f96bb07_20ee2288","updated":"2018-01-18 13:44:36.000000000","message":"This observation is spot on.  It\u0027s only a partial solution to include the relevant compute nodes in the provider summaries, though we should certainly do that in any case.  For each allocation request, we need to indicate some kind of \"anchor\".  Do we agree that there must always be exactly one non-sharing root provider associated with an AllocationRequest?  If so, one solution is to add a root_provider_uuid to AllocationRequest.  This entails a placement API change.\n\nAnother solution is to do as Tetsuro-san implies above, and include the non-sharing root with no resources.  This requires no change to the placement API.\n\n(BTW, that last entry, [(ss1, 100GB)], should *not* appear in the results, as it\u0027s not anchored.)","commit_id":"a9b0da7c9f9b93bc311f5ecf8737a47e1a7fd214"},{"author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"change_message_id":"0e9e6c9d7de69fa69c00c05f1230551de65a904a","unresolved":false,"context_lines":[{"line_number":1570,"context_line":"        # provider that aggregates the resources coming from ss1 and ss2 into a"},{"line_number":1571,"context_line":"        # single point. This problem reported in bug 1732731"},{"line_number":1572,"context_line":"        #"},{"line_number":1573,"context_line":"        # However today there is no way to express that we need"},{"line_number":1574,"context_line":"        # cn1 as a connection point but we allocate nothing from cn1."},{"line_number":1575,"context_line":"        # expected \u003d ["},{"line_number":1576,"context_line":"        #     [(\u0027cn1\u0027, \u003cnothing\u003e)"},{"line_number":1577,"context_line":"        #      (\u0027ss1\u0027, fields.ResourceClass.DISK_GB, 1500),"},{"line_number":1578,"context_line":"        #      (\u0027ss2\u0027, fields.ResourceClass.IPV4_ADDRESS, 2),"},{"line_number":1579,"context_line":"        #      (\u0027ss2\u0027, fields.ResourceClass.SRIOV_NET_VF, 1)],"},{"line_number":1580,"context_line":"        # ]"},{"line_number":1581,"context_line":"        # But we get nothing"},{"line_number":1582,"context_line":"        expected \u003d ["},{"line_number":1583,"context_line":"        ]"}],"source_content_type":"text/x-python","patch_set":9,"id":"7f96bb07_8aa30cb2","line":1580,"range":{"start_line":1573,"start_character":0,"end_line":1580,"end_character":11},"in_reply_to":"7f96bb07_dff55b58","updated":"2018-01-18 16:28:50.000000000","message":"\u003e In case of shared RPs I think the root_provider_id points to the\n \u003e shared RP itself. And from placement perspective it is still a\n \u003e valid anchor as placement should not know that nova can only\n \u003e consume a shared resource via a compute node. Other clients might\n \u003e consume it without a compute node (i.e. a backup solution that uses\n \u003e the centralized disk server for storing backups directly).\n\nHm, I think we should talk this through some more (like at the PTG).  We certainly need to be able to express that a request must be anchored to a non-sharing provider - that\u0027s certainly the use case for nova.  But is there a realistic scenario for an \"unanchored\" (sharing-only) claim?","commit_id":"a9b0da7c9f9b93bc311f5ecf8737a47e1a7fd214"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"5f76d7093472050d682b3562ee7c6ec9bd199521","unresolved":false,"context_lines":[{"line_number":1570,"context_line":"        # provider that aggregates the resources coming from ss1 and ss2 into a"},{"line_number":1571,"context_line":"        # single point. This problem reported in bug 1732731"},{"line_number":1572,"context_line":"        #"},{"line_number":1573,"context_line":"        # However today there is no way to express that we need"},{"line_number":1574,"context_line":"        # cn1 as a connection point but we allocate nothing from cn1."},{"line_number":1575,"context_line":"        # expected \u003d ["},{"line_number":1576,"context_line":"        #     [(\u0027cn1\u0027, \u003cnothing\u003e)"},{"line_number":1577,"context_line":"        #      (\u0027ss1\u0027, fields.ResourceClass.DISK_GB, 1500),"},{"line_number":1578,"context_line":"        #      (\u0027ss2\u0027, fields.ResourceClass.IPV4_ADDRESS, 2),"},{"line_number":1579,"context_line":"        #      (\u0027ss2\u0027, fields.ResourceClass.SRIOV_NET_VF, 1)],"},{"line_number":1580,"context_line":"        # ]"},{"line_number":1581,"context_line":"        # But we get nothing"},{"line_number":1582,"context_line":"        expected \u003d ["},{"line_number":1583,"context_line":"        ]"}],"source_content_type":"text/x-python","patch_set":9,"id":"7f96bb07_dff55b58","line":1580,"range":{"start_line":1573,"start_character":0,"end_line":1580,"end_character":11},"in_reply_to":"7f96bb07_f91ab76c","updated":"2018-01-18 14:48:14.000000000","message":"Eric\u0027s idea to have at least an anchor returned could make sense.\n\nIn a nested RP the anchor can naturally be the RP referred by the root_provider_id in the nested RP as the root is the highest level unique ancestor of the nested RP.\n\nIn case of shared RPs I think the root_provider_id points to the shared RP itself. And from placement perspective it is still a valid anchor as placement should not know that nova can only consume a shared resource via a compute node. Other clients might consume it without a compute node (i.e. a backup solution that uses the centralized disk server for storing backups directly).\n\nIt is a nova specialty that nova can only work with resources available _via_ a compute node. So nova has to adapt not placement. Right now we can simply assume that nova will not send such an allocation_candidate query where every resulting allocation candidate does not contain at least one RP that is either a compute RP or can be anchored via root_provider_id to a compute RP. \n\nSo my suggestion is to return anchors in the provider summaries based on the root_provider_id of the RPs in the allocation candidates.","commit_id":"a9b0da7c9f9b93bc311f5ecf8737a47e1a7fd214"},{"author":{"_account_id":25625,"name":"Tetsuro Nakamura","email":"tetsuro.nakamura.bc@hco.ntt.co.jp","username":"tetsuro0907"},"change_message_id":"879c0e81d6dc873740d165c952505dfb83343716","unresolved":false,"context_lines":[{"line_number":1582,"context_line":"        expected \u003d ["},{"line_number":1583,"context_line":"        ]"},{"line_number":1584,"context_line":"        self._validate_allocation_requests(expected, alloc_cands)"},{"line_number":1585,"context_line":""},{"line_number":1586,"context_line":"    def test_two_sharing_indirectly_connected_connecting_gives_resource(self):"},{"line_number":1587,"context_line":"        # This covers the following setup"},{"line_number":1588,"context_line":"        #        CN1 (VCPU, MEMORY_MB)"}],"source_content_type":"text/x-python","patch_set":9,"id":"7f96bb07_c0d09e22","line":1585,"updated":"2018-01-15 09:08:25.000000000","message":"good to add _validate_provider_summary_resources(expected, alloc_cands) for clarification.","commit_id":"a9b0da7c9f9b93bc311f5ecf8737a47e1a7fd214"}]}