[RFE] Onetime boot feature in OneView drivers

Bug #1666497 reported by Fellype Cavalcante
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ironic
In Progress
Low
Fellype Cavalcante

Bug Description

Non-persistent change in boot device order is supported by OneView drivers using iLO's one-time boot technology, allowing users to decide the boot device to be used for the next server power on.

In OneView, persistent boot device changes are performed updating the Server Profile and reapplying it strictly to a powered off server. Once the machine is powered on, the change is performed at BIOS settings and then the machine reboots to the desired device. Because of that, persistent changes in boot device for OneView managed machines are costly operations.

During cleaning and deployment phase, a couple of persistent changes are performed in a node, which implies in a considerable cost for the user that launches a bare metal instance using OneView drivers. We noticed that, during these phases there is a transient change from disk to PXE (in order to load IPA) and then the machine reverts the boot device order before delivering the instance to the user. We've seen that performing a non-persistent change in the boot device for these cases brings a performance improvement for OneView drivers.

We set a flag at prepare stage of these phases so that when the next boot device change is issued (the change to PXE device), OneViewManagement interface overrides Ironic default behavior and performs a non-persistent boot device change for this single moment. In doing so, OneView saves a Server Profile update and application to the node, finishing the cleaning/deployment a bit sooner.

Even though, attempting to perform an one-time boot device change in a non-supported hardware implies in the OneView drivers falling back to the persistent operation, we also propose a way to turn this behavior off for the scenarios where the administrator does not want to use this feature or they are sure that none of the available hardware support it.

Tags: oneview rfe
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to ironic (master)

Fix proposed to branch: master
Review: https://review.openstack.org/436469

Changed in ironic:
assignee: nobody → Fellype Cavalcante (fellypefca)
status: New → In Progress
Revision history for this message
Vladyslav Drok (vdrok) wrote : Re: The PXEBoot sets boot_device sets persistent True by default, not allowing the use of onetime boot by OneView Driver

As was commented on the patch, I'd like it to be fixed in oneview driver, without changing the defaults of the methods that are commonly used across code. If some new parameter needs to be added to some of the conductor methods, I think it's fine.

Changed in ironic:
importance: Undecided → Low
description: updated
summary: - The PXEBoot sets boot_device sets persistent True by default, not
- allowing the use of onetime boot by OneView Driver
+ Onetime boot feature in OneView drivers
Changed in ironic:
assignee: Fellype Cavalcante (fellypefca) → Xavier (marcusrafael)
summary: - Onetime boot feature in OneView drivers
+ Onetime boot features in OneView drivers
tags: added: oneview
summary: - Onetime boot features in OneView drivers
+ Onetime boot feature in OneView drivers
Changed in ironic:
assignee: Xavier (marcusrafael) → Fellype Cavalcante (fellypefca)
Dmitry Tantsur (divius)
summary: - Onetime boot feature in OneView drivers
+ [RFE] Onetime boot feature in OneView drivers
tags: added: rfe
Revision history for this message
Sam Betts (sambetts) wrote :

So looking at the code being discussed here I think there is some significant refactoring that needs to occur, the function try_set_boot_device https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/deploy_utils.py#L670 appears to be an IPMI driver specific function, yet is being called by the generic PXE driver https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/pxe.py#L488.

Also it appears that the helper function being called by https://github.com/openstack/ironic/blob/master/ironic/conductor/utils.py#L44 is left over from a time when node's could have no management interface.

My personal suggestion would be we kill the deploy_utils function for trying to set the boot device, each of the respective management interfaces e.g. IPMITool management should be dealing with their own issues. And then perhaps either add a configuration option to the [PXE] section in the config file or a driver_info option which defines if the PXE boot interface should request a persistent boot device or not.

Revision history for this message
Julia Kreger (juliaashleykreger) wrote :

So I'm good with this RFE for the following reasons;

* The driver team is making the changes with-in their driver.
* They are using the pre-existing interfaces to achieve improved interaction with their hardware. I.e. We have offered the wrapper interface around management interface from before there was a management interface as something for drivers to use. The contract as been established, it is inappropriate for us to ask teams to retool that to land that code. I guess what I'm trying to say is refactoring is on the core team. Not on someone trying to improve deployment times for users of their driver.
* It fits their needs, and makes it better for their users with-in the machine workflow.

This is a driver specific thing, we should let it in.

Revision history for this message
Sam Betts (sambetts) wrote :

Based on our conversation on IRC regarding the history behind the set boot device persistent option being a hack to support glitchy BMCs it gives me even more reason to suggest this becomes a per node configuration option, because then it gives the user who knows about their equipment to make the decision about persistence or not, something like driver_info boot_device_persistent = true/false, then if I discover my node is glitchy with persistent boot devices I can set it false or if I want to take advantage of my hardwares ability to set the boot device quicker I can set it false too

Revision history for this message
Julia Kreger (juliaashleykreger) wrote :

For IPMI, we essentially already provide the opposite item. The key takeaway with this "feature" for the oneview driver is to speed deployment by not forcing a complete profile application (along the lines of 10 minutes) by explicitly indicating that it is a one-time setting, which is completely a oneview centric interaction. It is almost as if this is a bug fix if looked at from just a oneview point of view.

description: updated
Revision history for this message
jiapei (jeremy.jia) wrote :

We're testing the set_boot_order of ironic driver these days with Ironic CLI. Below are what we find:
1. Input "ironic node-set-boot-device --persistent TEST_SERVER disk", this command will take effect, and the boot order will be updated in the backend server;
2. Input "ironic node-set-boot-device TEST_SERVER disk", this command won't take effect, and the boot order won't be updated in the backend server.

We've thought there maybe something wrong with the server hardware. After I see this RFE, I suspect that this is the default configuration(persistent is always TRUE) in Ironic, so we can't change the one time boot order??

Revision history for this message
Ricardo Araújo (ricardoas) wrote :

Discussion moved to https://bugs.launchpad.net/ironic/+bug/1701721
The RFE evolved to solve the problem in a more general way for Ironic.

Revision history for this message
Ricardo Araújo (ricardoas) wrote :

Hi, jiapei... it's not clear for me if you are using one of OneView drivers for this tests. This RFE was aiming at changing this behavior during the cleaning/deployment phase. Changes performed via CLI should be ok (to a certain point) for *_pxe_oneview drivers.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on ironic (master)

Change abandoned by Fellype Cavalcante (<email address hidden>) on branch: master
Review: https://review.openstack.org/436469

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.