[RFE] Onetime boot feature in OneView drivers

[Fellype Cavalcante]

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.

[OpenStack Infra (hudson-openstack)]

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

[Vladyslav Drok (vdrok)]

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.

[Sam Betts (sambetts)]

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.

[Julia Kreger (juliaashleykreger)]

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.

[Sam Betts (sambetts)]

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

[Julia Kreger (juliaashleykreger)]

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.

[jiapei (jeremy.jia)]

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？？

[Ricardo Araújo (ricardoas)]

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

[Ricardo Araújo (ricardoas)]

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.

[OpenStack Infra (hudson-openstack)]

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