Open Stack

On Mon, 10 Jun 2019 at 06:18, Alex Xu <soulxu at gmail.com> wrote:
>
>
>
> Eric Fried <openstack at 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.

We did consider using metadata. The problem is that it is
user-defined, so there is no way for an operator to restrict what can
be done by a user. Flavors are operator-defined and so allow for
selection from a 'menu' of types and configurations.

What might be nice is if we could use a flavor extra spec like this:

deploy-config:hyperthreading=enabled

The nova ironic virt driver could pass this to ironic, like it does with traits.

Then in the ironic deploy template, have fields like this:

name: Hyperthreading enabled
config-type: hyperthreading
config-value: enabled
steps: <deploy steps>

Ironic would then match on the config-type and config-value to find a
suitable deploy template.

As an extension, the deploy template could define a trait (or list of
traits) that must be supported by a node in order for the template to
be applied. Perhaps this would even be a standard relationship between
config-type and traits?

Haven't thought this through completely, I'm sure it has holes.

>
>> efried
>> .
>>