settingsLogin | Registersettings

[openstack-dev] [ironic][nova] Indivisible Resource Providers

0 votes

While discussing the proposal to add resourceclass' to Ironic nodes for interacting with the resource provider system in Nova with Jim on IRC, I voiced my concern about having a resourceclass per node. My thoughts were that we could achieve the behaviour we require by every Ironic node resource provider having a "baremetal" resource class of which they can own a maximum of 1. Flavor's that are required to land on a baremetal node would then define that they require at least 1 baremetal resource, along with any other resources they require. For example:

Resource Provider 1 Resources:
Baremetal: 1
RAM: 256
CPUs: 4

Resource Provider 2 Resources:
Baremetal: 1
RAM: 512
CPUs: 4

Resource Provider 3 Resources:
Baremetal: 0
RAM: 0
CPUs: 0

(Resource Provider 3 has been used, so it has zero resources left)

Given the thought experiment it seems like this would work great with one exception, if you define 2 flavors:

Flavor 1 Required Resources:
Baremetal: 1
RAM: 256

Flavor 2 Required Resources:
Baremetal: 1
RAM: 512

Flavor 2 will only schedule onto Resource Provider 2 because it is the only resource provider that can provide the amount of resources required. However Flavor 1 could potentially end up landing on Resource Provider 2 even though it provides more RAM than is actually required. The Baremetal resource class would prevent a second node from ever being scheduled onto that resource provider, so scheduling more nodes doesn't result on 2 instance on the same node, but it is an inefficient use of resources.

To combat this inefficient use of resources, I wondered if it was possible to add a flag to a resource provider to define that it is an indivisible resource provider, which would prevent flavors that don't use up all the resources a provider provides from landing on that provider.

Sam


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jul 27, 2016 in openstack-dev by Sam_Betts_(sambetts (1,840 points)   3
retagged Jan 26, 2017 by admin

2 Responses

0 votes

On Jul 27, 2016, at 9:48 AM, Sam Betts (sambetts) sambetts@cisco.com wrote:

While discussing the proposal to add resourceclass’ to Ironic nodes for interacting with the resource provider system in Nova with Jim on IRC, I voiced my concern about having a resourceclass per node. My thoughts were that we could achieve the behaviour we require by every Ironic node resource provider having a "baremetal" resource class of which they can own a maximum of 1. Flavor’s that are required to land on a baremetal node would then define that they require at least 1 baremetal resource, along with any other resources they require.

I was going to respond pointing out the issues with that approach, but then the rest of your email did just that. :)

I strongly preferred the approach that each particular hardware configuration would be a class, so that if you had 50 nodes with configuration A, and 20 nodes with configuration B, that that would be reflected in two resource classes, with corresponding inventories to match the nodes. When a node is provisioned, that inventory is decremented. This would be much more consistent with the rest of the resource provider design, as having many, many classes all of which represent identical hardware seems backwards.

-- Ed Leafe


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 27, 2016 by Ed_Leafe (11,720 points)   1 3 6
0 votes

On 07/27/2016 10:48 AM, Sam Betts (sambetts) wrote:
While discussing the proposal to add resourceclass’ to Ironic nodes for
interacting with the resource provider system in Nova with Jim on IRC, I
voiced my concern about having a resource
class per node. My thoughts
were that we could achieve the behaviour we require by every Ironic node
resource provider having a "baremetal" resource class of which they can
own a maximum of 1. Flavor’s that are required to land on a baremetal
node would then define that they require at least 1 baremetal resource,
along with any other resources they require. For example:

Resource Provider 1 Resources:
Baremetal: 1
RAM: 256
CPUs: 4

Resource Provider 2 Resources:
Baremetal: 1
RAM: 512
CPUs: 4

Resource Provider 3 Resources:
Baremetal: 0
RAM: 0
CPUs: 0

(Resource Provider 3 has been used, so it has zero resources left)

Given the thought experiment it seems like this would work great with
one exception, if you define 2 flavors:

Flavor 1 Required Resources:
Baremetal: 1
RAM: 256

Flavor 2 Required Resources:
Baremetal: 1
RAM: 512

Flavor 2 will only schedule onto Resource Provider 2 because it is the
only resource provider that can provide the amount of resources
required. However Flavor 1 could potentially end up landing on Resource
Provider 2 even though it provides more RAM than is actually required.
The Baremetal resource class would prevent a second node from ever being
scheduled onto that resource provider, so scheduling more nodes doesn’t
result on 2 instance on the same node, but it is an inefficient use of
resources.

To combat this inefficient use of resources, I wondered if it was
possible to add a flag to a resource provider to define that it is an
indivisible resource provider, which would prevent flavors that don’t
use up all the resources a provider provides from landing on that provider.

Hi Sam,

As Ed said, this isn't the direction we are going (in fact, it's
essentially the situation we are trying to get ourselves out of). The
new placement API has a resource provider record for each baremetal
resource node that Ironic exposes to tenants. Each of those resource
providers has an inventory record containing a total value of 1 for a
resource class that identifies the type of baremetal hardware (the
Ironic node class that is being currently introduced).

There are no inventory records for the VCPU or MEMORY_MB resource
classes for any resource provider that is an Ironic baremetal resource
node. The inventory is only a single unit of a dynamic resource class
that matches the Ironic node class -- thus representing the indivisible
nature of the baremetal resources.

Best,
-jay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 29, 2016 by Jay_Pipes (59,760 points)   3 11 14
...