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