[Yahoo-eng-team] [Bug 1792503] Re: allocation candidates "?member_of=" doesn't work with nested providers

2020-11-06 Thread Balazs Gibizer
** Changed in: nova
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1792503

Title:
  allocation candidates "?member_of=" doesn't work with nested providers

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) rocky series:
  Won't Fix

Bug 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. 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1792503/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1792503] Re: allocation candidates "?member_of=" doesn't work with nested providers

2019-03-04 Thread Chris Dent
** Changed in: nova/rocky
   Status: In Progress => Won't Fix

** Changed in: nova
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1792503

Title:
  allocation candidates "?member_of=" doesn't work with nested providers

Status in OpenStack Compute (nova):
  Fix Committed
Status in OpenStack Compute (nova) rocky series:
  Won't Fix

Bug 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. 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1792503/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1792503] Re: allocation candidates "?member_of=" doesn't work with nested providers

2018-12-04 Thread Tony Breeds
** Also affects: nova/rocky
   Importance: Undecided
   Status: New

** Changed in: nova/rocky
   Status: New => In Progress

** Changed in: nova/rocky
 Assignee: (unassigned) => Tetsuro Nakamura (tetsuro0907)

** Changed in: nova/rocky
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1792503

Title:
  allocation candidates "?member_of=" doesn't work with nested providers

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) rocky series:
  In Progress

Bug 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. 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1792503/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp