Adds virt and Hyper-V namespace and related traits

[claudiubelu]

No description provided.

[jaypipes]

This is a quantitative resource class, not a qualitative trait. As such, you should add a standard resource class to the nova/objects/fields.py:ResourceClass STANDARD enumeration for VIDEO_MEMORY_MB.

[claudiubelu]

Totally agree that vram is a quantitative resource, but at the moment, you cannot request different quantities than those present here (and the list might be extended in the future).

So, as far as traits / features / capabilities go, as a user, I would like to know these things before making a wrong request. Plus, I'd want in the future that nova will be able to quickly reject a request that needs another vram value.

This was the reasoning behind adding this as a trait. IMO, vram amount, in the case of hyper-v, can be considered as both trait, and consumable resource.

[jaypipes]

What the placement API is used to determine is whether a provider has enough capacity to handle some requested amount of resource.

If a Hyper-V compute node has 2048MB of video ram available, it would have an inventory record for resource class VIDEO_MEMORY_MB with a total of 2048. An image or flavor might have a requested amount of remotefx vram of any of the amounts you list above but that won't affect the accounting of the resources.

The inventory record could be:

 resource_provider_id: <UUID of compute node>
 resource_class_id: VIDEO_MEMORY_MB
 total: 2048
 reserved: 0
 min_unit: 64
 max_unit: 1024
 step_size: 64

That would solve most of the problems you indicate here. Note that the step_size is used to evaluate whether the requested amount of that resource class falls within a particular "step". When evaluating if the resource provider can meet a requested amount, we filter out providers by doing the following:

 WHERE (total - reserved) * allocation_ratio >= $REQUESTED_AMOUNT
 AND min_unit >= $REQUESTED_AMOUNT
 AND max_unit <= $REQUESTED_AMOUNT
 AND $REQUESTED_AMOUNT % step_size == 0

In the example of your vram resource classes, setting the step_size to 64 would eliminate all inventory records when requesting "bad" amounts of VIDEO_MEMORY_MB such as 1023 or 2040. Unfortunately, a requested amount of, say, 768 would not eliminate any inventory records because 768 modulo 64 equals 0.

To prevent this issue, we could also add an additional boolean field called "power_stepping" that would cause the requested amount to be evaluated against a power of the step_size field value instead of a modulo of the step_size.

For instance, let's say we had the following inventory record:

 resource_provider_id: <UUID of compute node>
 resource_class_id: VIDEO_MEMORY_MB
 total: 2048
 reserved: 0
 min_unit: 64
 max_unit: 1024
 step_size: 2
 power_stepping: true

Inventory records would then be eliminated using the following expression:

 WHERE (total - reserved) * allocation_ratio >= $REQUESTED_AMOUNT
 AND min_unit >= $REQUESTED_AMOUNT
 AND max_unit <= $REQUESTED_AMOUNT
 AND (
   (power_stepping == FALSE AND $REQUESTED_AMOUNT % step_size == 0)
   OR
   (power_stepping == TRUE AND (
      LOG($REQUESTED_AMOUNT) / LOG(step_size) == CAST(LOG($REQUESTED_AMOUNT) / LOG(step_size) AS INT)
      )
)

The above would filter out all inventories if the requested amount was not a power of 2.

[cdent]

While I recognize the value of the functionality provided by the concept of power_stepping I worry alot about the way in which the relatively simple original data model of resource providers with classes of inventories is growing limbs. My inclination would be that rather than extending the model to encompass lots of use cases which instead focus on the core use cases and address the edge cases at the edge (as in, in other tools).

I certainly appreciate that power_stepping is a generic solution to the problem presented by the OP, and that's great because it can solve more than that problem, but it is...smelly?

I feel a bit like the need to "quickly reject a request" need to be evaluated carefully and with due consideration for simplicity.

[jaypipes]

s/REMPOTEFX/REMOTEFX/g :)