summaryrefslogtreecommitdiff
path: root/ironic/drivers/modules/pxe.py
Commit message (Collapse)AuthorAgeFilesLines
* Fixes Secureboot with Anaconda deployNisha Agarwal2023-03-161-12/+3
| | | | | | | | | Fixes Secureboot with Anaconda deploy with PXE and iPXE Story:2010356 Task: 46529 Change-Id: Id6262654bb5e41e02c7d90b9a9aaf395e7b6a088
* Fix rebuilds using anaconda deploy interfaceRuby Loo2022-03-041-2/+13
| | | | | | | | | | | | | | The anaconda deploy interface was saving internal information in the node's instance_info, in the user-facing 'stage2' and 'ks_template' fields. This broke rebuilds using a different image with different stage2 or template specified in the image properties. This has been fixed by saving the information in the node's driver_internal_info instead. Addresses comments/nits from https://review.opendev.org/c/openstack/ironic/+/827924. Change-Id: Id9428518d21290fb38a0f7471a2cb69a6cb3ffb2
* More fixes for anaconda deploy interfaceRuby Loo2022-02-281-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The anaconda deploy interface has a few issues that are addressed here: - fixes logic in get_instance_image_info() for anaconda. If the ironic node's instance_info doesn't have both 'stage2' and 'ks_template' specified, we weren't using any values from the instance_info. This has been fixed to use values from instance_info if specified. Otherwise, they are set as follows: The 'stage2' value is taken from the image properties. We use the value for 'ks_template' if it is specified in the image properties. If not (since it is optional), we use the config option's '[anaconda]default_ks_template' value. setting. - For anaconda's stage2 directory, we were incorrectly creating a directory using the full path of the stage2 file. It now correctly creates the right directory. - The anaconda deploy interface expects the node's instance_info to be populated with the 'image_url'; added code to do that in PXEAnacondaDeploy's prepare() method. - When the deploy is finished and the bm node is being rebooted, we incorrectly set the node's provision state to 'active' instead of doing it via the provisioning state machine mechanism. - The code that was doing the validation of the kickstart file was incorrect and resulted in errors; this has been addressed. - The '%traceback' section in the packaged 'ks.cfg.template' file is deprecated and fails validation, so it has been removed. Change-Id: I953e948bcfa108d4c8e7b145da2f52b652e52a10
* Write initial grub config on startupSteve Baker2021-12-101-0/+1
| | | | | | | | | | | | | This change removes the documentation to copy master_grub_cfg.txt to /tftpboot/grub/grub.cfg and instead writes it on conductor startup. This grub config is a simple redirect config requested by grub network boot. "master" has been renamed to "initial" as a more accurate label of its function. New configuration option [pxe]initial_grub_template allows the deployer to specify a different initial grub template. Change-Id: I71191dd399a6c49607f91d69b5b1673799a38624
* Move place_loaders_for_boot to boot driver __init__Steve Baker2021-12-101-0/+6
| | | | | | | | | | | | Host preparation file writing is already done by the __init__ method of iPXEBoot. This change moves place_loaders_for_boot calls to iPXEBoot and PXEBoot to be consistent, and to only write the files when that driver is enabled. This will mean multiple writes of the same file when subclasses of these drivers are also enabled, but this overhead will be negligible. Change-Id: I7e17f4d1a54cd6c5d1a4bf006a0d42db8d123a46
* Fix various issues in the anaconda deploy interfaceArun S A G2021-10-271-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kickstart template expects a dictionary with 'ks_options' as the key. Instead build_kickstart_config_options function returns a dict with keys 'liveimg_url', 'agent_token' and 'heartbeat_url'. This change fixes this problem by returning a dictionary of dict with 'ks_options' as key and the dictionary with keys 'liveimg_url', 'agent_token' and heartbeat_url' as value. Fix a bug where the deploy() method of anaconda deploy interface where it did not return states.DEPLOYWAIT instead it returned 'None' which caused the instance to go straight to 'active' instead of 'wait call-back'. Fix issues in the default kickstart template where heartbeat was missing 'callback_url' parameter and the HTTP method should be 'POST' not 'PUT'. Fix issues with automated cleaning when anaconda deploy interface is used. Anaconda deploy interface could not deploy tarballs as the disk image sent to the anaconda interface via liveimg --url kickstart command does not include any file extension. When no file extension is present the kickstart command liveimg --url assumes the disk is a mountable partiton image. We fix this problem by enabling the user to specify file extensions using a glance image property named 'disk_file_extension' on the OS image. Co-Authored-By: Ruby Loo <opensrloo@gmail.com> Change-Id: I556f8c9efbc5ab0941513c3ecaa2aa3ca7f346ae
* Move ramdisk deploy to its own moduleDmitry Tantsur2021-09-061-69/+0
| | | | | | It does not depend on PXE and is actually often used with virtual media. Change-Id: Ida6edf819dbb3d1a51c465b4e109eafd977fd66c
* Fix ramdisk boot option handlingDmitry Tantsur2021-06-231-13/+0
| | | | | | | | | | | | | | | | | | | The current ramdisk deploy code expects a user to set the boot_option capability to "ramdisk". Not only is it redundant, it's also not documented, so chances are high nobody has ever done that. As a side effect of e6bb99cd8ff94a24c3f2108e649c7ca39189d220 boot interfaces no longer validate kernel/ramdisk/image if boot option is "local". Unless a user explicitly sets boot option to "ramdisk", the validation will be skipped for the ramdisk deploy. This patch follows the pattern of the anaconda deploy and makes get_boot_option always return "ramdisk" for the ramdisk deploy. In the future we need to refactor this code so that the deploy interface provides the boot option it works with, but that is a lot of changes. Change-Id: I25c28df048c706f0c5b013b4d252f09d5a7e57bd
* Add agent_status and agent_status_message params to heartbeatArun S A G2021-03-311-5/+100
| | | | | | | | | | | | | | | | | | | | agent_status is used by anaconda ramdisk to inform the conductor about state of the deployment. Valid agent states are 'start', 'end' and 'error'. The agent_status_message is used to describe the why the agent_status is set to a particular state. Use of these parameters require API version 1.72 or greater. When anaconda finishes deployment the agent_status is set to 'end'. When anaconda ramdisk is unable to deploy the OS for some reason the agent_status is set to 'error'. PXEAnacondaDeploy is implemented to handle the 'anaconda' deploy interface. PXEAnacondaDeploy ties to together pieces needed to deploy a node using anaconda ramdisk. Co-Authored-By: Jay Faulkner <jay@jvf.cc> Change-Id: Ieb452149730510b001c4712bbb2e0f28acfc3c2e
* Add anaconda configuration and templateArun S A G2021-03-191-0/+21
| | | | | | | | | | | | | | | | | | | | | This change adds 'anaconda' group and 'default_ks_template' configuration option under that group to ironic configuration file. Along with this change a new boot_option named 'kickstart' is added to identify anaconda kickstart deploy in the boot interface. deploy_utils.get_boot_option method is modified to check if node.deploy_interface is set to 'anaconda' and return boot_option 'kickstart'. This change also validates whether required parameters are set when the boot_option on the node is set to 'kickstart'. When boot_option is 'kickstart' we also validate if the glance image source has 'squashfs_id' property associated with it. Change-Id: I2ef7c33e2e63e6d08c084b4c5dbd77a44ddd2d14 Story: 2007839 Task: 41675
* Follow-up for ramdisk deploy configdrive supportDmitry Tantsur2021-01-111-6/+9
| | | | | | | 1) Do not issue a warning if the boot interface supports configdrive 2) Implement missing support for Swift URLs in configdrives Change-Id: I4b06478a14ab514d785f8e3972e5afbd79f8d3b5
* Include HeartbeatMixin in the ramdisk deployDmitry Tantsur2020-12-161-1/+2
| | | | | | | Otherwise cleaning gets stuck forever because there is no heartbeat implementation to use. Change-Id: I3589038001b98c866f47339ac8d65edfb891ed79
* Untie the ramdisk deploy from AgentDeployDmitry Tantsur2020-06-241-2/+5
| | | | | | | | | | | | | | | | | Currently PXERamdiskDeploy inherits AgentDeploy, which is unnecessary (it does not use in-band deploy steps or rely on heartbeats) and only happens to work because AgentDeploy has only one deploy step, which is not going to be the case soon. This change extracts common code for tear down and cleaning from ISCSIDeploy and AgentDeploy into the new AgentBaseMixin and makes PXERamdiskDeploy inherit it instead. Also removes the confusion AgentDeployMixin from iscsi_deploy. Change-Id: Ia6c2e3d98d74fc9c64268db04bc2fb7f5a6f0c1c Story: #2006963 Task: #40153
* Finalize removal of ipxe_enabled optionKaifeng Wang2020-02-211-78/+1
| | | | | | | | | | | Remove the dynamically registered ipxe_enabled option and say goodbye. Further extracts common bits to the PXEBaseMixin, tuning tests here and there. Story: 2007003 Task: 37779 Change-Id: I7c1b2a984d45bd63b4e95b62ce02960924c2ce17
* Start removing ipxe support from the pxe interfaceKaifeng Wang2020-02-211-213/+0
| | | | | | | | | | This patch starts removing codes related to ipxe support from the pxe interface, and extract common logic to the PXEBaseMixin. Story: 2007003 Task: 37779 Change-Id: Ia621f38d9b6c4570ba6a62ddb8c72244ff3fe33b
* Remove the [pxe]ipxe_enabled configuration optionKaifeng Wang2020-02-101-2/+1
| | | | | | | | | | | | | The ipxe_enabled configuration option was deprecated for quite a while, this patch removes it. However the code impact by simply removing the configuration option is quite large, so the strategy here is to register the option dynamically but sticks to False, which essentially disabled the ipxe support in the pxe interface. Story: 2007003 Task: 37779 Change-Id: I499e627f780b577e351fd39be5fa93a34d384e64
* Correct power state handling for managed in-band inspectionDmitry Tantsur2019-12-131-4/+2
| | | | | | | | | | | Do not try to configure networks when powered on, unless it's a node with a SmartNIC, in which case do power on before configuring networks. A new helper is created based on existing code in agent.py. Change-Id: I3a8fab7a39b604ed17a690fa9c31b3cd1dbdc6a7 Story: #1528920 Task: #37753
* Merge "Wire in in-band inspection for PXE boot and neutron-based networking"Zuul2019-11-261-14/+33
|\
| * Wire in in-band inspection for PXE boot and neutron-based networkingDmitry Tantsur2019-11-211-14/+33
| | | | | | | | | | | | | | | | | | This change implements in-band inspection support for PXE and iPXE boot interfaces and all in-tree network interfaces. Story: #1528920 Task: #23184 Change-Id: I470d55add73bae47a2755cde93d4b1e1f30e94a7
* | Backward compatibility for the ramdisk_params changeDmitry Tantsur2019-11-041-0/+3
|/ | | | | | | | | Follow-up to commit 08fe4af481444441084fa60cd0ff0246e5e65dcb restoring support for ipa-api-url in custom templates and adding a release note explaining the change. Story: #1528920 Change-Id: Ic8fc31fcde9a6f685bb1390a75a6a010c149f628
* Correct handling of ramdisk_params in (i)PXE bootDmitry Tantsur2019-10-281-2/+5
| | | | | | | | | | | | | Currently only ipa-api-url is recognized there, since it's hardcoded in the templates. Anything else is silently ignored. This patch fixes it by wiring all provided options in pxe_append_params and dropping the hardcoded ipa-api-url (provided by agent deploy). Add some logging to make debugging such issues easier. Change-Id: I573cf99d52a6965d64c2ed7a87cf901c12ea3fec Story: #1528920 Task: #37255
* Allow retrying PXE boot if it takes too longDmitry Tantsur2019-09-201-9/+1
| | | | | | | | | | | | | | PXE is inherently unreliable and sometimes times out without an obvious reason. It happens particularly often in resource constrained environments, such as the CI. This change allows an operator to set a timeout, after which the boot is retried again. The _add_node_filters call had to be refactored to avoid hitting the complexity limit. Change-Id: I34a11f52e8e98e5b64f2d21f7190468a9e4b030d Story: #2005167 Task: #29901
* Fix exception generation errorsJulia Kreger2019-04-041-3/+3
| | | | | | | | | | | | | | | | | | This patch addresses some frequently failing tests with a few minor changes related around how the exceptions are tested and how the data is passed to the exceptions that are failing. I've been able to duplicate the failing tests in CI while streaming video on my desktop of all things. With these changes, I've been unable to reproduce the failures. This also fixes entries for DeployTemplate generation which were noticed as well, however the failures were not observed in CI. And a missing i18n tag was added into the pxe code, where it was previously missing. Change-Id: I719fa12340b51c55c0441df572ee7e3b33b1910c
* Fix typo and docstring in pxe/ipxeHarald Jensås2019-03-081-4/+5
| | | | | | | | | | The docstring contains parameter mode which is not present. Move the param description to a comment in code where mode is resolved. Also fixes a typo in pxe_utils.py docstring. Change-Id: Ic0a31612023a4985178dbb6e3078dff53f0aba0a
* Merge "Add support for Smart NICs"Zuul2019-02-081-0/+3
|\
| * Add support for Smart NICsHamdy Khader2019-02-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend Ironic to enable use of Smart NICs to implement generic networking services for baremetal servers. Extending the ramdisk, direct, iscsi and ansible deployment Interfaces to support the Smart NIC use-cases. For Smart NIC use-case the baremetal node must be powered on and booted into bios then wait for agent that runs on the Smart NIC to be alive then do the network changes required. Task: #26932 Story: #2003346 Change-Id: I00d6f13dd991074e4f45ada4d7cf4ccc0edbc7e1
* | Optionally preserve original system boot order upon instance deploymentArne Wiebalck2019-02-071-4/+14
|/ | | | | | | | | | | | | | | By default, Ironic makes persistent changes to the system boot order at the end of an instance deployment. This may not be desired in all cases, e.g. when DC policies require to leave the persistent system boot order unchanged. While keeping the persistent approach as the default, this patch proposes to extent the existing 'force_persistent_boot_device' field in the node's driver_info for (i)PXE in a way that allows to have all boot device changes to be non-persistent. Change-Id: If3a19f74fb0dfbcff2cde4cd5a8cc1edf5de3058 Story: #2004846 Task: #29058
* Fix "import xxx as xxx" grammarzhu.fanglei2018-12-051-1/+1
| | | | | | This is to fix "import xxx as xxx" grammar. Change-Id: Ic76259aa1af39b81029b0ae15270cd27a2df43d0
* Cleanup of remaining pxe focused is_ipxe_enabledJulia Kreger2018-10-251-6/+13
| | | | | | | | | After this cleanup, only one use of is_ipxe_enabled remains which is in the storage interface. That will be removed in a separate patchset that I have been working on. Change-Id: I625ac56122ac4dd17d0c9e7dacc4444301a88e75 Story: 1628069
* Fix DHCPv6 supportJulia Kreger2018-10-241-4/+6
| | | | | | | | | | | | | | Adds logic to handle the appropriate replies for DHCPv6 responses. The IPv6 nature was discovered while researching differences and finding that the field ID value changes between IPv4 and IPv6 DHCP clients, as DHCPv6 is purely booting from a URL. Change-Id: I63572bea9bfb150aaeb4708dfa57e71adf4f64ab Task: 9788 Story: 1744620 Story: 2003934
* Create base pxe classJulia Kreger2018-10-221-69/+6
| | | | | | | | | | | | Create a base class to de-duplicate code across the pxe and ipxe interfaces. Only methods that do not have variation due to differences in iPXE behavior. Change-Id: I101f5ba7d44274d2b9d7d3a763198bc6fcc67e7a Task: 26738 Story: 1628069
* Wrap up PXE private method to pxe_utils moveJulia Kreger2018-10-221-88/+19
| | | | | | | | | | Moves the remaining private method test case code to pxe_utils and updates tests to remove the temporary method remappings in pxe.py. Change-Id: Ic9ae2ef2802f1f17b213d5a196dde3b65981f0d6 Task: 23029 Story: 1628069
* ipxe boot interfaceJulia Kreger2018-10-161-48/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A long time ago, in a galaxy not so far away, the ironic comunity reached consensus that we should refactor the PXE interface such that we had separate PXE and iPXE interfaces. In looking at what it would take for something like a standalone deployment to have multiarchitecture support in their environment, it seems even more urgent and necessary that we begin to make this delineation. This is because while some ARM iPXE support exists, the binary is not a commonly shipped artifiact, so operators are largely only left with grubaa64.efi as their bootloader. A similar issue exists with ppc64le deployments where they must disable iPXE, as the ppc64le hardware expects reading a syslinux compatible file, similarlly no iPXE loader exists. To start this effort, we need to promote iPXE functionality to a dedicated interface, and remove the necessity of setting the [pxe]ipxe_enabled setting. Next steps, beyond this patch, would be to begin to tease out the common private method code in the underlying PXE interface that both the iPXE and PXE interfaces use, and appropriately relocate and refactor that code as necesary. During this process, we can create an [ipxe] configuration section, and migrate settings. Finally, once the deprecation cycle is complete, we will be able to remove the ipxe logic with-in the PXE interface. Change-Id: I392616417c48986e84e50a3ddc7567344bfe3571 Story: #1628069 Task: #10516
* pxe/ipxe: Move common calls out pxe.pyJulia Kreger2018-09-261-318/+23
| | | | | | | | | | | | | Moves common method calls out of the body of pxe.py into pxe_utils, and accordingly removes some of the imports and re-maps the methods for compatability, as unit tests and methods have not yet been updated. Tests and methods will be updated in the next patch. Story: 1628069 Task: 26724 Change-Id: I717c49b99837b1785fc0080106414c6094dbf8eb
* Fix provisioning failure with `ramdisk` deploy interfaceShivanand Tendulker2018-08-251-30/+39
| | | | | | | | | | Provisioning fails if ironic node is configured with ``ramdisk`` deploy interface and PXE boot config file is not present for the node. Change-Id: Ic3a41b252751195a60e4757fee21cb2f62c3c7c2 Story: #2003532 Task: #24817
* Simplify subclasses for PXERamdiskDeployJim Rollenhagen2018-08-061-2/+1
| | | | | | | AgentDeploy already inherits from AgentDeployMixin and DeployInterface, so there's no need to list them here. Change-Id: Ia76e21330b012bdeb69a3d77b1544575d6d62513
* Follow-up patch to ramdisk interfaceJulia Kreger2018-07-301-26/+19
| | | | | | | | | * Breaks up and updates a few tests * Switches some checks to be capability based * Add decoratores to ramdisk deploy interface * Switches ramdisk deploy interface to use deploy_steps. Change-Id: Ief730a8bd9750a9ed6828506c3642f4dd7246c46
* Adds ramdisk deploy driverJulia Kreger2018-07-261-4/+109
| | | | | | | | | | | | | | | | | | | | | | | Adds a pxe deploy driver to support the concept of a deployment just consisting of a ramdisk. Ideally, as long as a kernel and ramdisk are defined, either by the operator or via a glance image, the PXE/iPXE template should point the booted kernel to using ramdisk as the root. In theory, this would allow deployment via nova, or directly using the parameters posted to the node's instance_info. There may be additional features realistically needed for this to be beyond minimally useful, but that would also depend on the contents of the ramdisk that is deployed by an API user. Change-Id: Id7067527cba27ed49753736f33ccb35e9b35bcba Story: 1753842 Task: 10666
* Move boot-related code to boot_mode_utils.pyIlya Etingof2018-06-201-3/+3
| | | | | | | | | This change collects boot-relalated functions into the `boot_mode_utils.py` module to improve code clarity. Change-Id: I1a2225d503deb382ba6021a6073c81cd03ca3175 Story: 1734131 Task: 10640
* Adds boot mode support to ManagementInterfaceIlya Etingof2018-06-151-0/+5
| | | | | | | | | | | | | | | | | | | | | This change introduces optional boot mode get/set methods to driver management interface [1] [2] alongside existing get/set boot device calls. The management interface is called at deploy time to synchronize BM machine boot mode setting with Ironic node configuration whenever needed. Also, this change introduces common exception class to be eventually used by the drivers to communicate their runtime errors to Ironic code in a uniformed way. 1. http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-01-09.log.html#t2018-01-09T15:54:16 2. http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-05-11.log.html#t2018-05-11T12:47:12 Story: 1734131 Task: 10640 Change-Id: If3db6ab8d3fae35d17808a231b7eecf11cf58327
* Fix authentication issues along with add multi extra volumesNguyen Van Trung2018-05-301-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit will fix authentication in boot from volume (BFV) feature, which use the volumes from Cinder for Baremetal via Ironic. Each volume will need pair of account for authentication when perform sanhook into SAN device via iPXE. And sandboot from drive 0x80 (default) also need pair accounts same with the iscsi sanhook on drive 0x80 with multi volumes has supported. NOTE: - We could add more than two volumes into iSCSI Boot Firmware Table(iBFT) - Due to Linux does not support an iBFT that has more than two volumes, thus BFV only support for add one etra volume. If over two volume in iBFT then machine will raise "iBFT error: Control header is invalid!". - Our code-base already for more than two volumes in iBFT, If Linux kernel bugs[1] is fixing this issue then we can use BFV with more than two volumes. Tested successfully on Fujitsu Baremetal Server TX2540 M1. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/acpi/actbl1.h#n1567 Co-authored-By: Hoang Trung Hieu <hieuht@vn.fujitsu.com> Co-authored-By: Dao Cong Tien <tiendc@vn.fujitsu.com> Change-Id: I98f658cced8491872d39adbd8e0a1a643dd24868 Story: #2001824 Task: #12573
* Remove excessive usage of mock_the_extension_manager in unit tests - part 2Dmitry Tantsur2018-05-241-1/+2
| | | | | | | | | Also fixes incorrect oneview tests that apparently used to be hidden by that. Similarly, insufficient mocking in the PXE boot interface tests was fixed. Now only test_manager uses mock_the_extension_manager. Change-Id: Iaef9555337919706cd165adbbb2e1be9322f80b7
* Fix W504 errorsJulia Kreger2018-05-091-15/+15
| | | | | | | | Also a few related errors based on some earlier investigation may have been pulled in along the lines of E305. Story: #2001985 Change-Id: Ifb2d3b481202fbd8cbb472e02de0f14f4d0809fd
* Fix ``agent`` deploy interface to call ``boot.prepare_instance``Shivanand Tendulker2018-04-181-1/+4
| | | | | | | | | | | | | | | ``agent`` deploy interface do not call ``boot.prepare_instance`` if image being provisioned is whole disk image. This commit fixes that issue. It also updates ``validate`` method of neutron network interface module to validate if it can support boot options requested for instance image. Change-Id: Ibd49d65f4512f2fa417794b66f4007d82f02e2ac Story: 1713916 Task: 9259 Story: 1750958 Task: 9288
* Set 'initrd' to 'rescue_ramdisk' for rescue with iPXEHironori Shiina2018-02-211-0/+2
| | | | | | | | | | The kernel paramter 'initrd' is hard-coded as 'deploy_ramdisk' in iPXE config template. A rescue ramdisk may fail to boot due to this wrong paramter. This patch sets this 'initrd' paramter properly to 'deploy_ramdisk' or 'rescue_ramdisk' by adding a new pxe option. Change-Id: I8ad1223dc289bbe915ee4ca8db66c8f80bf08f15 Closes-Bug: 1749860
* Build instance PXE options for unrescueHironori Shiina2018-02-191-7/+6
| | | | | | | | | | | This patch always builds PXE options for booting a user image even if the provision state is related to rescue mode. When the state is unrescuing, these options are necessary to boot a user image. When the provision state is rescuing, these options are just ignored because the PXE configuration is used at deployment mode. Change-Id: I1ff51cab120e6612c71e5d9c45cf28797bc16e76 Closes-Bug: 1749433
* Merge "Add validate_rescue() method to boot interface"Zuul2018-02-131-0/+20
|\
| * Add validate_rescue() method to boot interfaceShivanand Tendulker2018-02-091-0/+20
| | | | | | | | | | | | | | | | | | Adds validate_rescue() method to boot interface to validate node's boot properties related to rescue operation. This method is called by the validate() method of rescue interface. Closes-Bug: #1747467 Change-Id: Ib68d49a9cdb2ae4a5d43b90716c0a0c1166398c0
* | Remove validate_boot_option_for_trusted_boot metricRuby Loo2018-02-081-1/+0
|/ | | | | | | | | | This removes the timing metric "validate_boot_option_for_trusted_boot" because the validate_boot_parameters_for_trusted_boot() function is an internal function that is called by PXEBoot.validate() -- which is handled by the "PXEBoot.validate" metric. We shouldn't be emitting metrics for such short-lived, internal functions. Change-Id: Iaaa573fc4f128d6c3e20faf9c94259b352874eb8
* Remove mode argument from boot.(prepare|clean_up)_ramdiskJim Rollenhagen2018-02-011-4/+5
| | | | | | | | | | | | | | | | | | | | | Ideally, the boot interface shouldn't care if it's booting an image for deploy or rescue. The first step to unwinding this is not passing the mode argument into the boot interface - for now, we infer it from the state. Also stop validating whether the boot interface methods have a mode argument, as this is totally broken anyway (due to the decorator on the method). The rest of the boot interface's knowledge about deploy vs rescue can be eliminated in the future, as we shouldn't rework too much of that during feature freeze. We fix the bug in validation this way for now, for two reasons: * This argument really doesn't belong, and it's only been on master for six days. Get it out before people use it. * Library updates are currently frozen; fixing the decorator isn't an option right now. Change-Id: Icdeb870e9fd9cf836ff7ab97624189c8436adaba Closes-Bug: #1746730
View Lorry Controller Status