profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/MaXinjian/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Ma Xinjian MaXinjian FNST Nanjing, China

MaXinjian/baremetal-operator 0

Bare metal host provisioning integration for Kubernetes

MaXinjian/cluster-api 0

Home for the Cluster Management API work, a subproject of sig-cluster-lifecycle

MaXinjian/cluster-api-provider-metal3 0

Metal³ integration with https://github.com/kubernetes-sigs/cluster-api

MaXinjian/containerd 0

An open and reliable container runtime

MaXinjian/cri-tools 0

CLI and validation tools for Kubelet Container Runtime Interface (CRI) .

MaXinjian/Dragonfly 0

Dragonfly is an intelligent P2P based image and file distribution system.

MaXinjian/helm 0

The Kubernetes Package Manager

MaXinjian/ip-address-manager 0

IP address Manager for Cluster API Provider Metal3

push eventmetal3-io/metal3-docs

Michael Captain

commit sha 4a4ec75ca7d0fbb50223abd65c8c5b3303d4b817

Design: propose reproducible metal3-dev-env Includes user stories and work items

view details

metal3-io-bot

commit sha 44a86dbb780fed907abe54411a1a2688f5e6cae3

Merge pull request #178 from Nordix/design-reproducible-metal3-dev-env Design: propose reproducible metal3-dev-env

view details

push time in 5 days

pull request commentmetal3-io/metal3-docs

Design: propose reproducible metal3-dev-env

/lgtm

macaptain

comment created time in 5 days

pull request commentmetal3-io/metal3-docs

Design: propose reproducible metal3-dev-env

New changes are detected. LGTM label has been removed.

macaptain

comment created time in 5 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.++The BIOS Settings are retrieved from the BMC by Ironic and cached+whenever the node moves to `manageable` or `cleaning`, or when the settings+are updated. Recent changes to Ironic (see the Ironic proposal+[BIOS Registry](https://review.opendev.org/c/openstack/ironic-specs/+/774681)+added an additional query of the BIOS Registry.++The baremetal-operator can get the BIOS Settings from Ironic after the node+has been moved to manageable via the `v1/nodes/{node_ident}/bios?detail=True`+API.  This API provides a list of BIOS Settings (aka `Attributes`) in JSON and+each setting includes the following data:++- Name+- Value+- Registry information+  - Type (e.g. enum, string, integer, boolean, or password)+  - ReadOnly (a boolean indicating whether the attribute is read only)+  - Unique (indicating the value is specific to the host where it was+    retrieved)+  - Allowable values for enum type attributes+  - Minimum and maximum values (for numeric attributes)+  - Minimum and maximum character lengths (for string attributes)++Regarding the baremetal-operator states for when the data will be updated:++- The node first transitions to manageable during the `Registration` state, so+  at the end of that state `currentFirmwareSettings` will be populated.+- Settings can be updated during the `Preparing` state, so at the end of that+  state the settings will also be retrieved and used to update+  `currentFirmwareSettings`.++Upon retrieving the BIOS Settigs from Ironic, the baremetal-operator will+copy the name/value pairs to the `writeableFirmwareSettings` field in+`HostFirwareSettingsSpec` if that field is empty. Settings that have the+`read-only` flag set will not be copied as these settings cannot be written+to the BMC. Likewise, settings that have the `unique` flag set will also not+be copied, these are settings like serial numbers or product ids for example,+that should not be written to other servers.++A user can update `writeableFirmwareSettings` to the desired values for the+settings.  Likewise, `writeableFirmwareSettings` can be copied to multiple hosts+of the same type to effectively clone the settings from a reference host and+ensuring that all similar systems have the same BIOS configuration,+i.e. "bulk set".

Can you please elaborate a little bit more how the bulk copy process will work? From the description so far I wasn't able to find any templating feature so far, as mentioned at the beginning of the proposal

bfournie

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.

At any given time, how many CRD instances are expected to be present in the cluster (e.g. one for BMH, one for distinct vendor/server type, etc)? Also, considering that BMHs could be deployed in multiple namespaces, what would be the scope of the CRD?

bfournie

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to

For Metal3 here do you maybe mean BareMetalHost?

bfournie

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes

A link to the bios API here could be useful

bfournie

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.

Given that the name of the CRD is pretty specific and clear HostFirmwareSettings, what about reducing even further to spec.vendorSettings and status.schema?

@bfournie I think that in any case putting an example of the CRD help would be both useful as for documentation and to visualize it better for the ongoing discussion. For example, will the CRD have an id field to identify it? Do you plan to have additional fields for host selection?

bfournie

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.

I found a little bit confusing the usage of the term vendor-neutral here (and also just a few lines below), which seems to suggest a sort of in dependency amongst different vendors, whereas in the summary it's stated that the proposed approach applies just to similar servers from the same vendor

bfournie

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.++The BIOS Settings are retrieved from the BMC by Ironic and cached+whenever the node moves to `manageable` or `cleaning`, or when the settings+are updated. Recent changes to Ironic (see the Ironic proposal+[BIOS Registry](https://review.opendev.org/c/openstack/ironic-specs/+/774681)+added an additional query of the BIOS Registry.++The baremetal-operator can get the BIOS Settings from Ironic after the node+has been moved to manageable via the `v1/nodes/{node_ident}/bios?detail=True`+API.  This API provides a list of BIOS Settings (aka `Attributes`) in JSON and+each setting includes the following data:++- Name

For the sake of clarity, the Name will be vendor-specific

bfournie

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.++The BIOS Settings are retrieved from the BMC by Ironic and cached+whenever the node moves to `manageable` or `cleaning`, or when the settings+are updated. Recent changes to Ironic (see the Ironic proposal+[BIOS Registry](https://review.opendev.org/c/openstack/ironic-specs/+/774681)+added an additional query of the BIOS Registry.++The baremetal-operator can get the BIOS Settings from Ironic after the node+has been moved to manageable via the `v1/nodes/{node_ident}/bios?detail=True`+API.  This API provides a list of BIOS Settings (aka `Attributes`) in JSON and+each setting includes the following data:++- Name+- Value+- Registry information+  - Type (e.g. enum, string, integer, boolean, or password)+  - ReadOnly (a boolean indicating whether the attribute is read only)+  - Unique (indicating the value is specific to the host where it was+    retrieved)+  - Allowable values for enum type attributes+  - Minimum and maximum values (for numeric attributes)+  - Minimum and maximum character lengths (for string attributes)++Regarding the baremetal-operator states for when the data will be updated:++- The node first transitions to manageable during the `Registration` state, so+  at the end of that state `currentFirmwareSettings` will be populated.+- Settings can be updated during the `Preparing` state, so at the end of that+  state the settings will also be retrieved and used to update+  `currentFirmwareSettings`.++Upon retrieving the BIOS Settigs from Ironic, the baremetal-operator will+copy the name/value pairs to the `writeableFirmwareSettings` field in+`HostFirwareSettingsSpec` if that field is empty. Settings that have the+`read-only` flag set will not be copied as these settings cannot be written+to the BMC. Likewise, settings that have the `unique` flag set will also not+be copied, these are settings like serial numbers or product ids for example,+that should not be written to other servers.

Yes good point. I will note that settings that aren't in the spec but are in the status will be copied to the spec. I think this only needs to be done when the status is updated, e,g. after moving the node to manageable and getting the data from Ironic.

bfournie

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.++The BIOS Settings are retrieved from the BMC by Ironic and cached+whenever the node moves to `manageable` or `cleaning`, or when the settings+are updated. Recent changes to Ironic (see the Ironic proposal+[BIOS Registry](https://review.opendev.org/c/openstack/ironic-specs/+/774681)+added an additional query of the BIOS Registry.++The baremetal-operator can get the BIOS Settings from Ironic after the node+has been moved to manageable via the `v1/nodes/{node_ident}/bios?detail=True`+API.  This API provides a list of BIOS Settings (aka `Attributes`) in JSON and+each setting includes the following data:++- Name+- Value+- Registry information+  - Type (e.g. enum, string, integer, boolean, or password)+  - ReadOnly (a boolean indicating whether the attribute is read only)+  - Unique (indicating the value is specific to the host where it was+    retrieved)+  - Allowable values for enum type attributes+  - Minimum and maximum values (for numeric attributes)+  - Minimum and maximum character lengths (for string attributes)++Regarding the baremetal-operator states for when the data will be updated:++- The node first transitions to manageable during the `Registration` state, so+  at the end of that state `currentFirmwareSettings` will be populated.+- Settings can be updated during the `Preparing` state, so at the end of that+  state the settings will also be retrieved and used to update+  `currentFirmwareSettings`.++Upon retrieving the BIOS Settigs from Ironic, the baremetal-operator will+copy the name/value pairs to the `writeableFirmwareSettings` field in+`HostFirwareSettingsSpec` if that field is empty. Settings that have the+`read-only` flag set will not be copied as these settings cannot be written+to the BMC. Likewise, settings that have the `unique` flag set will also not+be copied, these are settings like serial numbers or product ids for example,+that should not be written to other servers.++A user can update `writeableFirmwareSettings` to the desired values for the+settings.  Likewise, `writeableFirmwareSettings` can be copied to multiple hosts+of the same type to effectively clone the settings from a reference host and+ensuring that all similar systems have the same BIOS configuration,+i.e. "bulk set".++The baremetal-operator will detect when `writeableFirmwareSettings` changes by+comparing the name/value pairs to `currentFirmwareSettings`. When a change is+detected, the BMO will add the new values to the Ironic clean-steps API. Before+adding it though, the BMO will do validation checks on the new values using the+Registry information in `currentFirmwareSettings`. For example, integer types+will checked against minimum and maximum parameters and enumeration types will+be compared against allowable values. The validation webhook can be leveraged+here to log a message regarding the failure; the invalid BIOS Setting will not+be added to clean-steps.++When settings are added to the Ironic clean-steps API Ironic, Ironic will set+the BIOS Configuration in the BMC as part of the manual cleaning process which+requires a reboot. Manual clean occurs in the Preparing state of the+BaremetalHost, the Host will re-enter this state from Ready/Available state+whenever its config differs from the last one it stored.++After applying the new BIOS Configuration, Ironic will then read and cache the+new BIOS Settings, which can be retrieved by the BMO and used to update+`currentFirmwareSettings`.++### Implementation Details/Notes/Constraints++One of the primary drivers of his design was that each vendor uses different+names and values for similar BIOS Configuration settings. This design does not+rely on vendor specific checks but instead uses common mechanisms to ensure+the BIOS Settings are valid:++- copying the names and values from `currentFirmwareSettings` to+  `writeableFirmwareSettings` ensures initial values are correct+- when updating the values in `writeableFirmwareSettings`, the user can use the+  limitations in the `currentFirmwareSettings`, e.g. minimum and maximum values+- before writing to the Ironic clean-steps API, the BMO runs validation checks+  against the `currentFirmwareSettings` to ensure updated values are valid++In order to interoperate with the individual BIOS Configuration set+approach the BMO must ensure that the same settings don't get added twice+to the Ironic clean-steps API. In addition, as each clean step requires a+reboot the number of clean steps that are added must be managed.++### Risks and Mitigations++N/A

I think we should show the readOnly data as its not sensitive, its normally things like NumCores or CoreSpeed which can't be changed. However some vendors, Dell in particular, make use of the "Password" AttributeType defined in https://redfish.dmtf.org/schemas/v1/AttributeRegistry.v1_3_5.json and include settings like "SysPassword" and "SetupPassword" with this AttributeType. In this case it looks like the values returned are either not included or set to the empty string but we should not include settings of this type in the currentValues and disallow any sets of this AttributeType.

I will add a note to this section

bfournie

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.

Thanks Zane! Agree that we can take "Firmware" out of the name since its redundant with that name in CRD itself, and also that using "settings" in both places is confusing.

For the spec section I think "vendorSettings" is good. For the status section, this includes both the name+value and the registry section so I don't think calling it firmwareRegistry is adequate. Maybe "currentValues"?

bfournie

comment created time in 8 days

pull request commentmetal3-io/metal3-docs

Design: propose reproducible metal3-dev-env

@macaptain: The following test failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
markdownlint 0deb56c9fa58dabb4ecc4c4ca5eed29872ce7edd link /test markdownlint

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. </details> <!-- test report -->

macaptain

comment created time in 8 days

pull request commentmetal3-io/metal3-docs

Design: propose reproducible metal3-dev-env

/retest

macaptain

comment created time in 8 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.++The BIOS Settings are retrieved from the BMC by Ironic and cached+whenever the node moves to `manageable` or `cleaning`, or when the settings+are updated. Recent changes to Ironic (see the Ironic proposal+[BIOS Registry](https://review.opendev.org/c/openstack/ironic-specs/+/774681)+added an additional query of the BIOS Registry.++The baremetal-operator can get the BIOS Settings from Ironic after the node+has been moved to manageable via the `v1/nodes/{node_ident}/bios?detail=True`+API.  This API provides a list of BIOS Settings (aka `Attributes`) in JSON and+each setting includes the following data:++- Name+- Value+- Registry information+  - Type (e.g. enum, string, integer, boolean, or password)+  - ReadOnly (a boolean indicating whether the attribute is read only)+  - Unique (indicating the value is specific to the host where it was+    retrieved)+  - Allowable values for enum type attributes+  - Minimum and maximum values (for numeric attributes)+  - Minimum and maximum character lengths (for string attributes)++Regarding the baremetal-operator states for when the data will be updated:++- The node first transitions to manageable during the `Registration` state, so+  at the end of that state `currentFirmwareSettings` will be populated.+- Settings can be updated during the `Preparing` state, so at the end of that+  state the settings will also be retrieved and used to update+  `currentFirmwareSettings`.++Upon retrieving the BIOS Settigs from Ironic, the baremetal-operator will+copy the name/value pairs to the `writeableFirmwareSettings` field in+`HostFirwareSettingsSpec` if that field is empty. Settings that have the+`read-only` flag set will not be copied as these settings cannot be written+to the BMC. Likewise, settings that have the `unique` flag set will also not+be copied, these are settings like serial numbers or product ids for example,+that should not be written to other servers.

Shouldn't we also copy missing values? e.g. if there are r/w settings A. B, and C available, but only a value for B specified, I think we should copy values for A and C into the Spec. It follows that we need to do this continuously, whenever they get out of sync.

bfournie

comment created time in 9 days

pull request commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: <a href="https://github.com/metal3-io/metal3-docs/pull/173#pullrequestreview-675504708" title="Approved">zaneb</a>

The full list of commands accepted by this bot can be found here.

The pull request process is described here

<details > Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":[]} -->

bfournie

comment created time in 9 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.++The BIOS Settings are retrieved from the BMC by Ironic and cached+whenever the node moves to `manageable` or `cleaning`, or when the settings+are updated. Recent changes to Ironic (see the Ironic proposal+[BIOS Registry](https://review.opendev.org/c/openstack/ironic-specs/+/774681)+added an additional query of the BIOS Registry.++The baremetal-operator can get the BIOS Settings from Ironic after the node+has been moved to manageable via the `v1/nodes/{node_ident}/bios?detail=True`+API.  This API provides a list of BIOS Settings (aka `Attributes`) in JSON and+each setting includes the following data:++- Name+- Value+- Registry information+  - Type (e.g. enum, string, integer, boolean, or password)+  - ReadOnly (a boolean indicating whether the attribute is read only)+  - Unique (indicating the value is specific to the host where it was+    retrieved)+  - Allowable values for enum type attributes+  - Minimum and maximum values (for numeric attributes)+  - Minimum and maximum character lengths (for string attributes)++Regarding the baremetal-operator states for when the data will be updated:++- The node first transitions to manageable during the `Registration` state, so+  at the end of that state `currentFirmwareSettings` will be populated.+- Settings can be updated during the `Preparing` state, so at the end of that+  state the settings will also be retrieved and used to update+  `currentFirmwareSettings`.++Upon retrieving the BIOS Settigs from Ironic, the baremetal-operator will+copy the name/value pairs to the `writeableFirmwareSettings` field in+`HostFirwareSettingsSpec` if that field is empty. Settings that have the+`read-only` flag set will not be copied as these settings cannot be written+to the BMC. Likewise, settings that have the `unique` flag set will also not+be copied, these are settings like serial numbers or product ids for example,+that should not be written to other servers.++A user can update `writeableFirmwareSettings` to the desired values for the+settings.  Likewise, `writeableFirmwareSettings` can be copied to multiple hosts+of the same type to effectively clone the settings from a reference host and+ensuring that all similar systems have the same BIOS configuration,+i.e. "bulk set".++The baremetal-operator will detect when `writeableFirmwareSettings` changes by+comparing the name/value pairs to `currentFirmwareSettings`. When a change is+detected, the BMO will add the new values to the Ironic clean-steps API. Before+adding it though, the BMO will do validation checks on the new values using the+Registry information in `currentFirmwareSettings`. For example, integer types+will checked against minimum and maximum parameters and enumeration types will+be compared against allowable values. The validation webhook can be leveraged+here to log a message regarding the failure; the invalid BIOS Setting will not+be added to clean-steps.++When settings are added to the Ironic clean-steps API Ironic, Ironic will set+the BIOS Configuration in the BMC as part of the manual cleaning process which+requires a reboot. Manual clean occurs in the Preparing state of the+BaremetalHost, the Host will re-enter this state from Ready/Available state+whenever its config differs from the last one it stored.++After applying the new BIOS Configuration, Ironic will then read and cache the+new BIOS Settings, which can be retrieved by the BMO and used to update+`currentFirmwareSettings`.++### Implementation Details/Notes/Constraints++One of the primary drivers of his design was that each vendor uses different+names and values for similar BIOS Configuration settings. This design does not+rely on vendor specific checks but instead uses common mechanisms to ensure+the BIOS Settings are valid:++- copying the names and values from `currentFirmwareSettings` to+  `writeableFirmwareSettings` ensures initial values are correct+- when updating the values in `writeableFirmwareSettings`, the user can use the+  limitations in the `currentFirmwareSettings`, e.g. minimum and maximum values+- before writing to the Ironic clean-steps API, the BMO runs validation checks+  against the `currentFirmwareSettings` to ensure updated values are valid++In order to interoperate with the individual BIOS Configuration set+approach the BMO must ensure that the same settings don't get added twice+to the Ironic clean-steps API. In addition, as each clean step requires a+reboot the number of clean steps that are added must be managed.++### Risks and Mitigations++N/A

I remember at some point we said there was no sensitive data being exposed, but I can't remember if we were proposing to show the read-only setting values at that time. Can you confirm that this is still the case?

bfournie

comment created time in 9 days

Pull request review commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

+<!--+ This work is licensed under a Creative Commons Attribution 3.0+ Unported License.++ http://creativecommons.org/licenses/by/3.0/legalcode+-->++# bulk-set-bios-config++## Status++implementable++## Summary++Provide the ability to set the same BIOS Configuration across multiple similar+servers from the same vendor. Retrieve the current BIOS Configuration settings+from the host via Ironic and use that as a template. Allow a user to set new+values for the BIOS Configuration which can be copied to multiple hosts of the+same type. Validate the values before sending to Ironic via the clean-steps API.++## Motivation++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired BIOS+configuration. This ensures all the machines will have the identical settings,+reducing issues caused by unexpected configuration differences.++The challenge that BIOS configuration presents is that no two hardware vendors+use the same names for settings that control the same behavior, and the+available settings often overlap but have significant differences. There+currently is an approach that would abstract these differences for individual+vendors+[individual set](https://github.com/metal3-io/baremetal-operator/pull/302).+This new proposal would not require Metal3 to+contain the vendor specific names, it will be entirely transparent and+inherently support all vendors. This new proposal could also work in+conjunction with the individual settings approach. A user could initially set+up a machine using that method and then push the configuration to multiple+machines as described here.++Most hardware vendors support a way to apply bulk settings, often by manually+configuring one host, exporting those settings in a vendor-specific file+format, and then importing that file on the BMCs of other hosts. Accepting that+the format for these profiles is vendor-specific eliminates a lot of the+implementation complexity, at the risk of moving that complexity to the+end-user. This requirement is similar to something Dell has proposed in the+Ironic community+([hw config](https://review.opendev.org/c/openstack/ironic-specs/+/740721))+to export and import an entire system iDRAC inventory including RAID and+networking requirements. Compared to that approach, this proposal attempts+a more lightweight, vendor-neutral approach just for BIOS configuration.++### Goals++Provide a vendor-neutral approach of updating BIOS configuration in a bulk+manner across all similar hardware. Create a template for the current+BIOS configurations settings cached on a server. Give access to the BIOS+registry which can be used as documentation so a user can easily update+the BIOS settings to desired values. Validate the BIOS Configuration+values based on the vendor's BIOS Registry before sending to the BMC.++### Non-Goals++This proposal does not attempt to fulfill the following goals:++- Allow the transfer of BIOS configuration between different vendor’s+  servers or different vendor models+- Support bulk set of other configurations besides BIOS+- Provide storage mechanism for BIOS settings++## Proposal++### User Stories++#### Story 1++When provisioning a large amount of machines with identical settings, our+customers want to provide a known, validated payload with all the desired+firmware configuration.++This ensures all the machines will have the identical settings, reducing issues+caused by unexpected configuration differences.++Since the name/value pair mapping is vendor specific and not intuitive, it+doesn’t lend itself to creating the input by hand using existing vendor+documentation, except for potentially a small subset of names. It’s desirable+to take an existing BIOS config set and modify the current settings to the+desired settings. The BIOS Registry can be used as a source of documentation+to modify the settings.++## Design Details++This proposes a new Custom Resource Definition (CRD) to store the settings+read from Ironic along with the modified settings to write to Ironic. Since+each vendor provides 100 or more BIOS Settings, its not practical to store+these in the BareMetalHost CRD. The new CRD will be named+`HostFirmwareSettings` and will consist of the following:++- `currentFirmwareSettings` - the current BIOS Settings retrieved from Ironic+  via the bios API will be stored in the Status section. This dataset includes+  BIOS Registry information which provides a schema for the settings.+- `writeableFirmwareSettings` - BIOS Settings to write to the host via Ironic+  will be stored in the Spec section. If it is empty, it will be initially+  populated with the name/value pairs from `currentFirmwareSettings` that do+  not have the `read-only` or `unique` flag set.

I think we're ready for the bikeshed-on-naming portion of the discussion :grin: Some thoughts:

  • "desired" might be better than "writeable", but...
  • it's kind of implied by the Spec/Status split that the Spec is the desired state and the Status is the current state
  • the status.currentFirmwareSettings contains not only the settings but the whole schema. Calling them both "settings" might be confusing as it implies they have the same structure.

What would folks think about something like spec.vendorSettings and status.firmwareRegistry?

bfournie

comment created time in 9 days

pull request commentmetal3-io/metal3-docs

Design: propose reproducible metal3-dev-env

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: <a href="https://github.com/metal3-io/metal3-docs/pull/178#pullrequestreview-653441113" title="Approved">namnx228</a>, <a href="https://github.com/metal3-io/metal3-docs/pull/178#issuecomment-853976095" title="Approved">zaneb</a>

The full list of commands accepted by this bot can be found here.

The pull request process is described here

<details > Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":[]} -->

macaptain

comment created time in 9 days

pull request commentmetal3-io/metal3-docs

Design: propose reproducible metal3-dev-env

/approve

macaptain

comment created time in 9 days

pull request commentmetal3-io/metal3-docs

Fix a typo in the custom deploy design

/lgtm

dtantsur

comment created time in 9 days

pull request commentmetal3-io/metal3-docs

Design: propose reproducible metal3-dev-env

@maelk @hardys @dhellmann Last meeting we agreed on lazy consensus and as I can see there were no further comments to be addressed on this proposal. As such, can we merge the proposal and move on with its implementation ?

macaptain

comment created time in 10 days

push eventmetal3-io/metal3-docs

Zane Bitter

commit sha 842394d74c834d2c0073820284945dbd97e2bd09

Propose deploy ramdisk Image build API and integration Enable a custom image containing the ironic-python-agent to be built for each BareMetalHost, instead of requiring all hosts to use the same agent image. The interface to the image builder will be defined by a new RamDiskImageRequest CR in metal³, with users able to substitute their own implementations of image building (in most cases this is expected to involve light customisation of an existing image) by creating a controller. The baremetal-operator will create and use RamDiskImageRequests as required when configured to do so. This allows users to customise the ramdisk for each Host to contain network settings specific to that host.

view details

metal3-io-bot

commit sha 8e8dba068df0e1760149684045017a09ffa54275

Merge pull request #183 from zaneb/image-builder-integration Propose deploy ramdisk Image build API and integration

view details

push time in 10 days

PR merged metal3-io/metal3-docs

Reviewers
Propose deploy ramdisk Image build API and integration approved lgtm size/L

Enable a custom image containing the ironic-python-agent to be built for each BareMetalHost, instead of requiring all hosts to use the same agent image. The interface to the image builder will be defined by a new RamDiskImageRequest CR in metal³, with users able to substitute their own implementations of image building (in most cases this is expected to involve light customisation of an existing image) by creating a controller. The baremetal-operator will create and use RamDiskImageRequests as required when configured to do so.

This allows users to customise the ramdisk for each Host to contain network settings specific to that host.

+284 -0

21 comments

1 changed file

zaneb

pr closed time in 10 days

pull request commentmetal3-io/metal3-docs

Propose deploy ramdisk Image build API and integration

Since there were on objections/further comments within the last week (after we agreed on lazy consensus), I am going to merge this proposal. /lgtm

zaneb

comment created time in 10 days

pull request commentmetal3-io/metal3-docs

Add proposal to do bulk set of BIOS configuration

Hi! As agreed during the community meeting, let's have a lazy consensus of a week from today and if there are no further objections/comments on the proposal, we can go ahead with merging it next week.

bfournie

comment created time in 10 days

pull request commentmetal3-io/metal3-docs

Update Remediation Controller proposal

As agreed during the community meeting, let's have a lazy consensus of a week from today and if no objections, we can merge it next week.

jan-est

comment created time in 10 days

issue commentmetal3-io/metal3-docs

FR: Network configuration integration

/remove-lifecycle stale This is still on-going

maelk

comment created time in 11 days