Eric Fried <openstack@fried.cc> 于2019年6月7日周五 上午1:59写道：
> Looking at the specs, it seems it's mostly talking about changing VMs resources without rebooting. However that's not the actual intent of the Ironic use case I explained in the email.
> Yes, it requires a reboot to reflect the BIOS changes. This reboot can be either be done by Nova IronicDriver or Ironic deploy step can also do it.
> So I am not sure if the spec actually satisfies the use case.
> I hope to get more response from the team to get more clarity.

Waitwait. The VM needs to be rebooted for the BIOS change to take
effect? So (non-live) resize would actually satisfy your use case just
fine. But the problem is that the ironic driver doesn't support resize
at all?

Without digging too hard, that seems like it would be a fairly
straightforward thing to add. It would be limited to only "same host"
and initially you could only change this one attribute (anything else
would have to fail).

Nova people, thoughts?


Contribute another idea.

So just as Jay said in this thread. Those CUSTOM_HYPERTHREADING_ON and CUSTOM_HYPERTHREADING_OFF are configuration. Those
configuration isn't used for scheduling. Actually, Traits is designed for scheduling.

So yes, there should be only one trait. CUSTOM_HYPERTHREADING, this trait is used for indicating the host support HT. About whether enable it in the instance is configuration info.

That is also pain for change the configuration in the flavor. The flavor is the spec of instance's virtual resource, not the configuration.

So another way is we should store the configuration into another place. Like the server's metadata.

So for the HT case. We only fill the CUSTOM_HYPERTHREADING trait in the flavor, and fill a server metadata 'hyperthreading_config=on' in server metadata. The nova will find out a BM node support HT. And ironic based on the server metadata 'hyperthreading_config=on' to enable the HT.

When change the configuration of HT to off, the user can update the server's metadata. Currently, the nova will send a rpc call to the compute node and calling a virt driver interface when the server metadata is updated. In the ironic virt driver, it can trigger a hyper-threading configuration deploy step to turn the HT off, and do a reboot of the instance. (The reboot is a step inside deploy-step, not part of ironic virt driver flow)
 
But yes, this changes some design to the original deploy-steps and deploy-templates. And we fill something into the server's metadata which I'm not sure nova people like it.

Anyway, just put my idea at here.

efried
.