<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Mark Goddard <<a href="mailto:mark@stackhpc.com">mark@stackhpc.com</a>> 于2019年6月12日周三 下午2:45写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 12 Jun 2019, 06:23 Alex Xu, <<a href="mailto:soulxu@gmail.com" target="_blank">soulxu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Mark Goddard <<a href="mailto:mark@stackhpc.com" rel="noreferrer" target="_blank">mark@stackhpc.com</a>> 于2019年6月12日周三 上午1:39写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 10 Jun 2019 at 06:18, Alex Xu <<a href="mailto:soulxu@gmail.com" rel="noreferrer" target="_blank">soulxu@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> Eric Fried <openstack@fried.cc> 于2019年6月7日周五 上午1:59写道：<br>
>><br>
>> > 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.<br>
>> > 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.<br>
>> > So I am not sure if the spec actually satisfies the use case.<br>
>> > I hope to get more response from the team to get more clarity.<br>
>><br>
>> Waitwait. The VM needs to be rebooted for the BIOS change to take<br>
>> effect? So (non-live) resize would actually satisfy your use case just<br>
>> fine. But the problem is that the ironic driver doesn't support resize<br>
>> at all?<br>
>><br>
>> Without digging too hard, that seems like it would be a fairly<br>
>> straightforward thing to add. It would be limited to only "same host"<br>
>> and initially you could only change this one attribute (anything else<br>
>> would have to fail).<br>
>><br>
>> Nova people, thoughts?<br>
>><br>
><br>
> Contribute another idea.<br>
><br>
> So just as Jay said in this thread. Those CUSTOM_HYPERTHREADING_ON and CUSTOM_HYPERTHREADING_OFF are configuration. Those<br>
> configuration isn't used for scheduling. Actually, Traits is designed for scheduling.<br>
><br>
> 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.<br>
><br>
> That is also pain for change the configuration in the flavor. The flavor is the spec of instance's virtual resource, not the configuration.<br>
><br>
> So another way is we should store the configuration into another place. Like the server's metadata.<br>
><br>
> 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.<br>
><br>
> 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)<br>
><br>
> 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.<br>
><br>
> Anyway, just put my idea at here.<br>
<br>
We did consider using metadata. The problem is that it is<br>
user-defined, so there is no way for an operator to restrict what can<br>
be done by a user. Flavors are operator-defined and so allow for<br>
selection from a 'menu' of types and configurations.<br></blockquote><div><br></div><div>The end user can change the BIOS config by the ipmi inside the guest OS, and do a reboot. It is already out of control for the operator.</div><div>(Correct me if ironic doesn't allow the end user change the config inside the guest OS)</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It depends. Normally you can't configure BIOS via IPMI, but need to use a vendor interface such as racadm or on hardware that supports it, Redfish. Access to the management controller can and should be locked down though. It's also usually possible to reconfigure via serial console, if this is exposed to users.</div></div></blockquote><div><br></div><div>It sounds that breaking the operator control partially.</div><div><br></div><div>(Sorry for drop the mallist thread again...I will paste a note to the wall "click the "Reply All"...")</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>So Flavor should be thing to strict the resource( or resource's capable) which can be requested by the end user. For example, flavor will say I need a BM node has hyper-thread capable. But enable or disable can be controlled by the end user.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What might be nice is if we could use a flavor extra spec like this:<br>
<br>
deploy-config:hyperthreading=enabled<br>
<br>
The nova ironic virt driver could pass this to ironic, like it does with traits.<br>
<br>
Then in the ironic deploy template, have fields like this:<br>
<br>
name: Hyperthreading enabled<br>
config-type: hyperthreading<br>
config-value: enabled<br>
steps: <deploy steps><br>
<br>
Ironic would then match on the config-type and config-value to find a<br>
suitable deploy template.<br>
<br>
As an extension, the deploy template could define a trait (or list of<br>
traits) that must be supported by a node in order for the template to<br>
be applied. Perhaps this would even be a standard relationship between<br>
config-type and traits?<br>
<br>
Haven't thought this through completely, I'm sure it has holes.<br>
<br>
><br>
>> efried<br>
>> .<br>
>><br>
</blockquote></div></div>
</blockquote></div></div></div>
</blockquote></div></div>