We've experienced different firmware update approaches.. this is a wish list
rather than a requirement since in the end, it can all be scripted if needed.
Currently, these are manpower intensive and require a lot of co-ordination
since the upgrade operation has to be performed by the hardware support team
but the end user defines the intervention window.
a. Some BMC updates can be applied out of band, over the network with
appropriate BMC rights. It would be very nice if Ironic could orchestrate these
updates since they can be painful to organise. One aspect of this would be for
Ironic to orchestrate the updates and keep track of success/failure along with
the current version of the BMC firmware (maybe as a property?). Typical example
of this is when a security flaw is found in a particular hardware model BMC and
we want to update to the latest version given an image provided by the vendor.
b. A set of machines have been delivered but an incorrect BIOS setting is
found. We want to reflash the BIOSes with the latest BIOS code/settings. This
would generally be an operation requiring a reboot. We would ask our users to
follow a procedure at their convenience to do so (within a window) and then we
would force the change. An inventory of the current version would help to
identify those who do not do the update and remind them.
c. A disk firmware issue is found. Similar to b) but there is also the
possibility for partial completion where some disks correctly update but others
not.
Overall, it would be great if we can find a way to allow self service hardware
management where the end users can choose the right point to follow the
firmware update process within a window and then we can force the upgrade if
they do not do so.
Tim
-Original Message-
From: Julia Kreger <juliaashleykre...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: Friday, 30 March 2018 at 00:09
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [ironic] baremetal firmware lifecycle management
One of the topics that came up at during the Ironic sessions at the
Rocky PTG was firmware management.
During this discussion, we quickly reached the consensus that we
lacked the ability to discuss and reach a forward direction without:
* An understanding of capabilities and available vendor mechanisms
that can be used to consistently determine and assert desired firmware
to a baremetal node. Ideally, we could find a commonality of two or
more vendor mechanisms that can be abstracted cleanly into high level
actions. Ideally this would boil down to something a simple as
"list_firmware()" and "set_firmware()". Additionally there are surely
some caveats we need to understand, such as if the firmware update
must be done in a particular state, and if a particular prior
condition or next action is required for the particular update.
* An understanding of several use cases where a deployed node may need
to have specific firmware applied. We are presently aware of two
cases. The first being specific firmware is needed to match an
approved operational profile. The second being a desire to perform
ad-hoc changes or have new versions of firmware asserted while a node
has already been deployed.
Naturally any insight that can be shared will help the community to
best model the interaction so we can determine next steps and
ultimately implementation details.
-Julia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
