Open Stack

Hi All,

Thank you for your responses.

I agree with Mark here, the example stated here fits the Boolean case(feature enable/disable). However many other BIOS feature doesn’t fits the case. For example enabling Intel Speed Select also needs 3 configuration or traits:

CUSTOM_ISS_CONFIG_BASE – 00
CUSTOM_ISS_CONFIG_1 – 01
CUSTOM_ISS_CONFIG_2 - 02

Each configuration/trait here represents different profiles to be set on the baremetal server. Does resize help with such use case?

Regards,
Madhuri

From: Mark Goddard [mailto:mark at stackhpc.com]
Sent: Sunday, June 9, 2019 3:23 PM
To: Jay Pipes <jaypipes at gmail.com>
Cc: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [Nova][Ironic] Reset Configurations in Baremetals Post Provisioning


On Fri, 7 Jun 2019, 18:02 Jay Pipes, <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote:
On 6/7/19 11:23 AM, Eric Fried wrote:
>> Better still, add a standardized trait to os-traits for hyperthreading
>> support, which is what I'd recommended in the original
>> cpu-resource-tracking spec.
>
> HW_CPU_HYPERTHREADING was added via [1] and has been in os-traits since
> 0.8.0.

I think we need a tri-state here. There are three options:

1. Give me a node with hyperthreading enabled
2. Give me a node with hyperthreading disabled
3. I don't care

For me, the lack of a trait is 3 - I wouldn't want existing flavours without this trait to cause hyperthreading to be disabled.

The ironic deploy templates feature wasn't designed to support forbidden traits - I don't think they were implemented at the time. The example use cases so far have involved encoding values into a trait name, e.g. CUSTOM_HYPERTHREADING_ON. Forbidden traits could be made to work in this case, but it doesn't really extend to non Boolean things such as RAID levels.

I'm not trying to shoot down new ideas, just explaining how we got here.


Excellent, I had a faint recollection of that...

-jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190611/15be18cc/attachment-0001.html>