Open Stack

On 07/27/2016 10:48 AM, Sam Betts (sambetts) wrote:
> While discussing the proposal to add resource_class’ 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