Add new CRDs for BIOS configuration#901
Conversation
|
Hi @bfournie. Thanks for your PR. I'm waiting for a metal3-io member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
e1c67be to
3f1e24d
Compare
|
/ok-to-test |
3f1e24d to
4d738ef
Compare
4d738ef to
8ea3b5a
Compare
8ea3b5a to
5af4aeb
Compare
5af4aeb to
38d9da7
Compare
|
/test-integration |
|
/lgtm |
|
@elfosardo: adding LGTM is restricted to approvers and reviewers in OWNERS files. DetailsIn response to this:
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. |
9afde93 to
a6b9b66
Compare
|
|
||
| // The count of the number of times this schema is used by | ||
| // a HostFirmwareSettings resource | ||
| ReferenceCount int `json:"referenceCount" required:"true"` |
There was a problem hiding this comment.
If there's a reason to have a Status it would probably be just for this. You can't write the Status atomically with creating (or updating) the resource though, so I suspect this would also do better in the Spec.
TBH I'm not entirely convinced a reference count is the best way to manage cleanup, but I'm withholding judgement on that.
There was a problem hiding this comment.
Sure can move this to Spec.
There was a problem hiding this comment.
I've been reading up on Garbage Collection in k8s, and I think we should be able to use the owner references to manage this automatically (saves a lot of work implementing this in the controller). You can have multiple owner references, which I didn't know before. (Only one of these can be marked as a 'controller', which is what we do for Secrets so that's what confused me. However, we don't need to do that here.)
So it's safe to ditch this field.
| FirmwareSchema *SchemaReference `json:"schema,omitempty"` | ||
|
|
||
| // Settings are the actual firmware settings stored as name/value pairs | ||
| // +patchStrategy=merge |
There was a problem hiding this comment.
This is more important on the Spec than the Status.
There was a problem hiding this comment.
As per the doc, the Settings in the Status would contain all the settings read from Ironic and, upon reading, the BMO would copy these settings to the Spec but only include those that do not have the "ReadOnly" or "Unique" set in the FirmwareSchema for this setting. The Values in the Spec could then be easily updated by the user without having to change/write the Names. The BMO can compare the spec values to the expected values in the Status and only send the differences to clean steps. So with that design we'd need Settings in both places.
There was a problem hiding this comment.
I meant the +patchStrategy=merge :)
db13966 to
59df014
Compare
|
/test-integration |
59df014 to
0b67ebb
Compare
|
/test-integration |
2 similar comments
|
/test-integration |
|
/test-integration |
zaneb
left a comment
There was a problem hiding this comment.
This looks basically good. Couple of very minor things inline.
0b67ebb to
9712791
Compare
9712791 to
9e08275
Compare
Add a new CRD for the FirmwareSettings for BIOS configuration as described in the spec - metal3-io/metal3-docs#173. A new CRD is necessary since its not practical to include the number of settings in BareMetalHost.
9e08275 to
a425cf1
Compare
|
/test-integration |
dtantsur
left a comment
There was a problem hiding this comment.
/approve
Looks good to me, but please consider fixing my comments in a follow-up.
| type SettingSchema struct { | ||
|
|
||
| // The type of setting. | ||
| // +kubebuilder:validation:Enum=Enumeration;String;Integer;Boolean;Password |
There was a problem hiding this comment.
Do we expect to support non-Redfish implementation? If yes, we cannot add this validation.
There was a problem hiding this comment.
Yes, for non-redfish types there will be no BIOS registry data returned and therefore no schema, so no validations can be done on the settings. I will note this in the CRD.
There was a problem hiding this comment.
Well, other drivers may decide to implement schema as well.
| return false | ||
| } | ||
|
|
||
| if schema.ReadOnly != nil && *schema.ReadOnly == true { |
There was a problem hiding this comment.
I wonder if we need any logging in this function. Otherwise debugging can be challenging.
Or can we maybe return an error instead and log it somewhere at the caller place?
There was a problem hiding this comment.
Good point about the debugging, I will add more granular debugging to help determine error in settings.
There was a problem hiding this comment.
Changed CheckSettingIsValid() in #938 to return an error which is now logged.
|
[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 |
Add a new CRD for the HostFirmwareSettings for BIOS configuration as described in the spec - metal3-io/metal3-docs#173. A new CRD is necessary since its not practical to include the number of settings in BareMetalHost.
In addition a CRD is added for the FirmwareSchema used to provide a schema for setting the firmware values.