Open Stack

Mark Goddard <mark at stackhpc.com> 于2019年6月12日周三 下午2:45写道：

>
>
> On Wed, 12 Jun 2019, 06:23 Alex Xu, <soulxu at gmail.com> wrote:
>
>>
>>
>> Mark Goddard <mark at stackhpc.com> 于2019年6月12日周三 上午1:39写道：
>>
>>> 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.
>>>
>>
>> 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.
>> (Correct me if ironic doesn't allow the end user change the config inside
>> the guest OS)
>>
>
> 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.
>

It sounds that breaking the operator control partially.

(Sorry for drop the mallist thread again...I will paste a note to the wall
"click the "Reply All"...")


>
>> 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.
>>
>>
>>>
>>> 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
>>> >> .
>>> >>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190613/973b330c/attachment.html>