[Nova][Ironic] Reset Configurations in Baremetals Post Provisioning
jaypipes at gmail.com
Fri Jun 7 12:07:19 UTC 2019
On 6/7/19 2:53 AM, Kumari, Madhuri wrote:
> Hi Jay,
>> -----Original Message-----
>> From: Jay Pipes [mailto:jaypipes at gmail.com]
>> The absence of a trait on a provider should be represented by the provider
>> not having a trait. Just have a single trait "CUSTOM_HYPERTHREADING" that
>> you either place on the provider or do not place on a provider.
>> The flavor should then either request that the trait be present on a provider
>> that the instance is scheduled to
>> (trait:CUSTOM_HYPERTHREADING=required) or that the trait should *not*
>> be present on a provider that the instance is scheduled to
> I understand that these traits are used for scheduling while server create in Nova. Whereas these traits means more to Ironic. Ironic runs multiple deploy steps matching the name of traits in flavor.
> The use case explained in the email is about changing some BIOS configuration post server create. By changing the trait in flavor from CUSTOM_HYPERTHREADING_ON to CUSTOM_HYPERTHREADING_OFF, Ironic should run the matching deploy step to disable hyperthreading in BIOS and do a reboot.
> But currently there isn't a way in Nova about telling Ironic about the trait has changed in flavor, so perform the corresponding deploy steps.
>  https://docs.openstack.org/ironic/stein/admin/node-deployment.html#matching-deploy-templates
Yes, I understand that theses aren't really traits but are actually
However, what I'm saying is that if you pass the flavor information
during resize (as Eric has suggested), then you don't need *two* trait
strings (one for CUSTOM_HYPERTHREADING_ON and one for
CUSTOM_HYPERTHREADING_OFF). You only need the single
CUSTOM_HYPERTHREADING trait and the driver should simply look for the
absence of that trait (or, alternately, the flavor saying "=forbid"
instead of "=required".
Better still, add a standardized trait to os-traits for hyperthreading
support, which is what I'd recommended in the original
More information about the openstack-discuss