Open Stack

Hi All,

Thank you everyone for your responses.

We have created an etherpad[1] with suggested solution and concerns. I request Nova and Ironic developers to provide their input on the etherpad.

[1] https://etherpad.openstack.org/p/ironic-nova-reset-configuration

Regards,
Madhuri
From: Alex Xu [mailto:soulxu at gmail.com]
Sent: Thursday, June 13, 2019 11:25 AM
To: Mark Goddard <mark at stackhpc.com>; openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [Nova][Ironic] Reset Configurations in Baremetals Post Provisioning


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

On Wed, 12 Jun 2019, 06:23 Alex Xu, <soulxu at gmail.com<mailto:soulxu at gmail.com>> wrote:


Mark Goddard <mark at stackhpc.com<mailto:mark at stackhpc.com>> 于2019年6月12日周三 上午1:39写道：
On Mon, 10 Jun 2019 at 06:18, Alex Xu <soulxu at gmail.com<mailto:soulxu at gmail.com>> wrote:
>
>
>
> Eric Fried <openstack at fried.cc<mailto: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/13b38bed/attachment-0001.html>