[openstack-dev] [nova] FFE request for passing capabilities in the flavor to ironic
Hi, I would like to ask for a feature freeze exception for passing capabilities in the flavor to Ironic: https://blueprints.launchpad.net/nova/+spec/pass-flavor-capabilities-to-ironic-virt-driver Addressed by: https://review.openstack.org/136104 Pass on the capabilities in the flavor to the ironic Addressed by: https://review.openstack.org/141012 Pass on the capabilities to instance_info several Ironic Kilo features including secure boot, trusted boot, and local boot support with partition image are depending on this feature. It also has impact on Ironic vendor driver's hardware property introspection feature. Code changes to support this spec in Nova ironic virt driver is very small- only 31 lines of code (including comments) in nova/virt/ironic/patcher.py, and 22 lines of code in test_patcher.py. Please consider approving this FFE. Thanks! Regards, wanyen __ 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-dev] [Ironic] UEFI boot design spec no longer requires Nova changes
Hi, The UEFI Boot design spec https://review.openstack.org/#/c/99850https://review.openstack.org/#/c/99850/7 has removed its Nova dependencies. The new version of the spec uses compute capabilities filter to support UEFI only or BIOS only boot mode. The capability filter is already supported by Ironic therefore the UEFI boot design spec does not require changes in Nova scheduler nor Nova Ironic virt driver. Please consider this spec for Juno. Thanks! Regards, wanyen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] comment on IceHouse firmware update etherpad
Hi, I read the etherpad for firmware update.I have a comment: * if the node already has an instance on it, do we want to be able to update the firmware o tenant shouldn't care/know about firmware updates o need to migrate off first, so no o i.e. we can't disrupt the tenant IMO the decision should be pending on platform capability. Some platforms can stage firmware update online or update firmware online. Therefore, it is fine to update firmware on those platforms even when instances are running on them. IMO Ironic should let platform to decide whether it can update firmware or stage firmware update when a node already has an instance on it. I think this can be done via an API. Thanks! Regards, WH ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
