Create and manage hostFirmwareSettings and firmwareSchema resources#938
Conversation
99046c3 to
4cc75d1
Compare
|
/test-integration |
4cc75d1 to
f744f9f
Compare
|
/test-integration |
f744f9f to
b2e0b54
Compare
|
/test-integration |
b2e0b54 to
8a6033d
Compare
|
/test-integration |
a31b9c2 to
aa9509c
Compare
|
/test-integration |
aa9509c to
0766e06
Compare
|
/test-integration |
dtantsur
left a comment
There was a problem hiding this comment.
I haven't finished the review, but here are some comments.
cb2c990 to
dfdf13f
Compare
|
/test-integration |
dfdf13f to
a206781
Compare
|
/test-integration |
|
/test-integration |
dtantsur
left a comment
There was a problem hiding this comment.
I'm leaving a bunch of comments here. Most are nits except for two:
- A question/suggestion on API fields
- A concern about updating Spec automatically.
35f9dfc to
5265479
Compare
794bfa7 to
b7a96e7
Compare
b7a96e7 to
3fa388b
Compare
|
/test-integration |
3fa388b to
23b89fb
Compare
|
/test-integration |
|
/approve Thanks! |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dtantsur, elfosardo The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Thanks for the effort @bfournie, it seems that all the points have been addressed. /lgtm |
zaneb
left a comment
There was a problem hiding this comment.
I don't see any code to move the state back to Preparing (from Ready) if the settings are out of date. We'll also need to watch the HostFirmwareSettings in the BMH controller so we'll see if the Spec changes while we're in the Ready state.
Re copying the Status fields to the Spec, I don't think ironic changing the fields is a problem because we were only going to do a copy if that field wasn't mentioned in the Spec, so it wouldn't overwrite an existing value. However, given that we're using a comparison of Spec and Status to determine when config has drifted, perhaps it's for the best if we only include values the user has specifically said they care about.
| if err = r.Get(ctx, req.NamespacedName, hfs); err != nil { | ||
| if k8serrors.IsNotFound(err) { | ||
| // A resource doesn't exist, create one | ||
| if err = r.newHostFirmwareSettings(info, req.NamespacedName); err != nil { |
There was a problem hiding this comment.
So this controller watches the BaremetalHost and automatically creates a HostFirmwareSettings object for it if it doesn't exist?
This is slightly unorthodox and will result in a lot of extra reconciles (every time the BMH changes we'll have to re-run this) but I guess it should be ok. We'll need to make doubly sure there are no unnecessary writes, otherwise we could get an infinite recursion between the two controllers.
| firmwareSchema = &metal3v1alpha1.FirmwareSchema{ | ||
| ObjectMeta: metav1.ObjectMeta{ | ||
| Name: schemaName, | ||
| Namespace: info.hfs.ObjectMeta.Namespace, |
There was a problem hiding this comment.
We talked about adding a CLI option to put these into a fixed namespace (regardless of which namespace the BMH is in) when the operator is running cluster-wide.
There was a problem hiding this comment.
Yes that is still in plan as a follow on PR.
| h.Write([]byte(fmt.Sprintf("%v", keys))) | ||
| hash := fmt.Sprintf("%x", h.Sum(nil))[:8] | ||
|
|
||
| return "schema-" + hash |
There was a problem hiding this comment.
IIRC we decided to put the vendor and model in the name as well as the shortened hash. Did that turn out not to be feasible?
There was a problem hiding this comment.
That ended up causing problems since the vendor and model come from introspection data and that may not have been retrieved yet when the resource is created. if its retrieved later the hashing will be incorrect.
There was a problem hiding this comment.
I thought we wouldn't have the schema data available until after inspection either?
There is something to be said for not mixing data from two different sources though, since they could change independently.
There was a problem hiding this comment.
There's not a dependency on inspection to get the schema data as we get the schema directly from the BMC while we get the inspection data from IPA. So yeah I don't we should use the vendor/model in the name.
| func GetSchemaName(schema map[string]metal3v1alpha1.SettingSchema) string { | ||
|
|
||
| // Schemas from the same vendor and model should be identical for both keys and values. | ||
| // Hash the keys of the map to get a identifier unique to this schema. |
There was a problem hiding this comment.
Why not include the values as well? Just having the keys sounds like it would risk collisions between different firmware versions.
There was a problem hiding this comment.
I'm not sure if we would practically see differences in values but I'll add the values into the hash to prevent that happening.
Change to use the Preparing state end time as a trigger that cleaning has just completed instead of relying on state difference. In addition, the following changes were made to address follow-on comments in metal3-io#938. - added Preparing state to OperationalMetrics so its end time can be used for level-trigger - split Status Settings into LocalData (ReadOnly or Unique fields) and writeable Settings - changed name of condition `UpdateRequested` to `FirmwareSettingsChangeDetected` - add each hostFirmwareSettings as owner of its FirmwareSchema so that garbage collection can be done - Change the SetOwnerReference/SetControllerReference calls to before Create so the Update could be removed - When building BIOS settings for cleaning make sure the hfs settings don't overwrite the vendor-agnostic settings - When generating the hash for the firmwareSchema include the schema values in addition to the names in the hash
Change to use the Preparing state end time as a trigger that cleaning has just completed instead of relying on state difference. In addition, the following changes were made to address follow-on comments in metal3-io#938. - added Preparing state to OperationalMetrics so its end time can be used for level-trigger - split Status Settings into LocalData (ReadOnly or Unique fields) and writeable Settings - changed name of condition `UpdateRequested` to `FirmwareSettingsChangeDetected` - add each hostFirmwareSettings as owner of its FirmwareSchema so that garbage collection can be done - Change the SetOwnerReference/SetControllerReference calls to before Create so the Update could be removed - When building BIOS settings for cleaning make sure the hfs settings don't overwrite the vendor-agnostic settings - When generating the hash for the firmwareSchema include the schema values in addition to the names in the hash
Change to use the Preparing state end time as a trigger that cleaning has just completed instead of relying on state difference. In addition, the following changes were made to address follow-on comments in metal3-io#938. - added Preparing state to OperationalMetrics so its end time can be used for level-trigger - split Status Settings into LocalData (ReadOnly or Unique fields) and writeable Settings - changed name of condition `UpdateRequested` to `FirmwareSettingsChangeDetected` - add each hostFirmwareSettings as owner of its FirmwareSchema so that garbage collection can be done - Change the SetOwnerReference/SetControllerReference calls to before Create so the Update could be removed - When building BIOS settings for cleaning make sure the hfs settings don't overwrite the vendor-agnostic settings - When generating the hash for the firmwareSchema include the schema values in addition to the names in the hash
Change to use the Preparing state end time as a trigger that cleaning has just completed instead of relying on state difference. In addition, the following changes were made to address follow-on comments in metal3-io#938. - added Preparing state to OperationalMetrics so its end time can be used for level-trigger - split Status Settings into LocalData (ReadOnly or Unique fields) and writeable Settings - changed name of condition `UpdateRequested` to `FirmwareSettingsChangeDetected` - add each hostFirmwareSettings as owner of its FirmwareSchema so that garbage collection can be done - Change the SetOwnerReference/SetControllerReference calls to before Create so the Update could be removed - When building BIOS settings for cleaning make sure the hfs settings don't overwrite the vendor-agnostic settings - When generating the hash for the firmwareSchema include the schema values in addition to the names in the hash
Change to use the Preparing state end time as a trigger that cleaning has just completed instead of relying on state difference. In addition, the following changes were made to address follow-on comments in metal3-io#938. - added Preparing state to OperationalMetrics so its end time can be used for level-trigger - split Status Settings into LocalData (ReadOnly or Unique fields) and writeable Settings - changed name of condition `UpdateRequested` to `FirmwareSettingsChangeDetected` - add each hostFirmwareSettings as owner of its FirmwareSchema so that garbage collection can be done - Change the SetOwnerReference/SetControllerReference calls to before Create so the Update could be removed - When building BIOS settings for cleaning make sure the hfs settings don't overwrite the vendor-agnostic settings - When generating the hash for the firmwareSchema include the schema values in addition to the names in the hash
Change to use the Preparing state end time as a trigger that cleaning has just completed instead of relying on state difference. In addition, the following changes were made to address follow-on comments in metal3-io#938. - added Preparing state to OperationalMetrics so its end time can be used for level-trigger - split Status Settings into LocalData (ReadOnly or Unique fields) and writeable Settings - changed name of condition `UpdateRequested` to `FirmwareSettingsChangeDetected` - add each hostFirmwareSettings as owner of its FirmwareSchema so that garbage collection can be done - Change the SetOwnerReference/SetControllerReference calls to before Create so the Update could be removed - When building BIOS settings for cleaning make sure the hfs settings don't overwrite the vendor-agnostic settings - When generating the hash for the firmwareSchema include the schema values in addition to the names in the hash
Change to use the Preparing state end time as a trigger that cleaning has just completed instead of relying on state difference. In addition, the following changes were made to address follow-on comments in metal3-io#938. - added Preparing state to OperationalMetrics so its end time can be used for level-trigger - split Status Settings into LocalData (ReadOnly or Unique fields) and writeable Settings - changed name of condition `UpdateRequested` to `FirmwareSettingsChangeDetected` - add each hostFirmwareSettings as owner of its FirmwareSchema so that garbage collection can be done - Change the SetOwnerReference/SetControllerReference calls to before Create so the Update could be removed - When building BIOS settings for cleaning make sure the hfs settings don't overwrite the vendor-agnostic settings - When generating the hash for the firmwareSchema include the schema values in addition to the names in the hash
After inspection the baremetalhost_controller retrieve BIOS settings from Ironic and will create the hostFirmwareSettings and firmwareSchema (if BIOS registry data is received) resources. In Preparing, any Spec settings that have been changed will be used to build clean_steps containing the BIOS settings. The changed values will be verified against the expected limits in the firmwareSchema, any failures will case an error in Preparing. The building of clean steps also uses the 3 BIOS settings that were added to the BMH CRD (#302).
The new hostfirmwarecontroller also does validation on the input values but only logs failures. As a follow-on PR, a validation webhook will be used to validate the input values.
See also metal3-io/metal3-docs#173