Activity log for bug #1792503

Date Who What changed Old value New value Message
2018-09-14 04:56:18 Tetsuro Nakamura bug added bug
2018-09-14 05:03:34 Tetsuro Nakamura tags placement
2018-09-14 05:03:41 Tetsuro Nakamura description "GET /allocation_candidates" now supports "member_of" parameter. With nested providers present, this should work with the following constraints. (a) With "member_of" qparam, aggregates on the root should span on the whole tree If a root provider is in the aggregate, which has been specified by "member_of" qparam, the resource providers under that root can be in allocation candidates even the root is absent. (b) Without "member_of" qparam, sharing resource provider should be shared with the whole tree If a sharing provider is in the same aggregate with one resource provider (rpA), and "member_of" hasn't been specified in qparam by user, the sharing provider can be in allocation candidates with any of the resource providers in the same tree with rpA. (c) With "member_of" qparam, the range of the share of sharing resource providers should shrink to the resource providers "under the specified aggregates" in a tree. Here, whether the rp is "under the specified aggregates" is determined with the constraints of (a). Namely, not only rps that belongs to the aggregates directly are "under the aggregates", but olso rps whose root is under the aggregates are also "under the aggregates". So far at Stein PTG time, 2018 Sep. 13th, this constraint is broken in the point that when placement picks up allocation candidates, the aggregates of nested providers are assumed as the same as root providers, which means it ignores the aggregates of the nested provider itself. This results in the lack of allocation candidates when an aggregate which is on a nested provider but not on the root are specified in member_of parameter. This bug is well described in a test case which is submitted shortly. "GET /allocation_candidates" now supports "member_of" parameter. With nested providers present, this should work with the following constraints. --------------------------------------------- (a) With "member_of" qparam, aggregates on the root should span on the whole tree If a root provider is in the aggregate, which has been specified by "member_of" qparam, the resource providers under that root can be in allocation candidates even the root is absent. (b) Without "member_of" qparam, sharing resource provider should be shared with the whole tree If a sharing provider is in the same aggregate with one resource provider (rpA), and "member_of" hasn't been specified in qparam by user, the sharing provider can be in allocation candidates with any of the resource providers in the same tree with rpA. (c) With "member_of" qparam, the range of the share of sharing resource providers should shrink to the resource providers "under the specified aggregates" in a tree. Here, whether the rp is "under the specified aggregates" is determined with the constraints of (a). Namely, not only rps that belongs to the aggregates directly are "under the aggregates", but olso rps whose root is under the aggregates are also "under the aggregates". --------------------------------------------- So far at Stein PTG time, 2018 Sep. 13th, this constraint is broken in the point that when placement picks up allocation candidates, the aggregates of nested providers are assumed as the same as root providers. This means it ignores the aggregates of the nested provider itself. This could result in the lack of allocation candidates when an aggregate which on a nested provider but not on the root has been specified in the `member_of` query parameter. This bug is well described in a test case which is submitted shortly.
2018-09-14 05:04:17 Tetsuro Nakamura nominated for series nova/rocky
2018-10-22 12:24:04 Tetsuro Nakamura nova: assignee Tetsuro Nakamura (tetsuro0907)
2018-10-22 12:24:21 Tetsuro Nakamura nova: importance Undecided Medium
2018-10-22 12:24:28 Tetsuro Nakamura nova: status New In Progress
2018-12-05 04:46:06 Tony Breeds bug task added nova/rocky
2018-12-05 04:46:16 Tony Breeds nova/rocky: status New In Progress
2018-12-05 04:46:33 Tony Breeds nova/rocky: assignee Tetsuro Nakamura (tetsuro0907)
2018-12-05 04:46:37 Tony Breeds nova/rocky: importance Undecided Medium
2019-03-04 13:46:27 Chris Dent nova/rocky: status In Progress Won't Fix
2019-03-04 13:46:55 Chris Dent nova: status In Progress Fix Committed
2020-11-06 08:42:18 Balazs Gibizer nova: status Fix Committed Fix Released