-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add extended hardware information to Server and ServerClass CRDs #735
Conversation
👷 Deploy request for wonderful-swartz-a1308c pending review. 🔨 Explore the source changes: 3571b80 |
Cordoned bool `json:"cordoned,omitempty"` | ||
PXEBootAlways bool `json:"pxeBootAlways,omitempty"` | ||
EnvironmentRef *corev1.ObjectReference `json:"environmentRef,omitempty"` | ||
Hardware *HardwareInformation `json:"hardware,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a breaking change for the CRDs, as the fields were removed. We could do also migration and new CRD version, but that might need more changes. I wonder if we could still keep things same way in the CRDs, even if we restructure the fields in Go structs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that is also what I was struggling with. I agree not breaking things is better, but I honestly don't know a good way.
A partial migration should be possible I think, although it will probably always lead to incomplete information (for example servers with multiple CPU's will only have 1 listed). Also we would only have a few fields of the new set available.
I'm not sure what is worse: not having information or having incomplete information...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 for a new CRD version and we do CRD migrations, it'll be less visible changes for a user
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree we should probably do new API version and migration, but this means we should also fix the webhooks for this controller (it's right now broken/missing) and go all the way with proper migration. And if we do that, should we do more changes as well?
@lion7 we really like the proposed changes here, but as we would need to do CRD migration, we would like to delay that for the next release of Sidero (0.6.0). We need to fix the webhooks first in the controllers and implement proper migration |
I totally agree. Is there a timeline on the next release? Like in the order of days / weeks / months? Anyway, I'll see if I can improve this PR by implementing the proposed changes. |
f28d80c
to
e5d71a7
Compare
I moved my CRD changes to a new version and implemented the manual conversions that were needed. This should not break things I hope. I am not entirely sure about the whole conversion part though. The conversions for the |
1a0dc09
to
b0cd6ea
Compare
1b80b9a
to
3571b80
Compare
bf99ecc
to
e72fead
Compare
I also added network interfaces to the collected information, so we have the complete set of data from servers. @smira there are some (un)related changes in this PR that I'd like to separate in other PR's so the diff will be smaller. I also want to move the Kustomize config changes to a different PR, there are quite a few of them in order to get the whole webhook stuff working. Still working on that one. |
ad036ed
to
1136eb0
Compare
Display the extendend hardware information that was added via siderolabs/sidero#735 in the Theila UI Signed-off-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl>
Display the extendend hardware information that was added via siderolabs/sidero#735 in the Theila UI Signed-off-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl>
9208c33
to
68482af
Compare
This change adds detailed hardware information to the Server CRD. Hardware info is extracted by the agent from SMBIOS. The ServerClass CRD is also updated so more precise qualifiers can be used. Signed-off-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl>
Display the extendend hardware information that was added via siderolabs/sidero#735 in the Theila UI Signed-off-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl>
Display the extendend hardware information that was added via siderolabs/sidero#735 in the Theila UI Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
Display the extendend hardware information that was added via siderolabs/sidero#735 in the Theila UI Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
Display the extendend hardware information that was added via siderolabs/sidero#735 in the Theila UI Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
Display the extendend hardware information that was added via siderolabs/sidero#735 in the Theila UI Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
Display the extendend hardware information that was added via siderolabs/sidero#735 in the Theila UI Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
This is basically subset of PR siderolabs#735 with only CRD changes without actual code changes to use new CRDs. As storage version is v1alpha2, every access goes twice via conversion webhooks (for better test coverage). Other parts of siderolabs#735 will be incorporated in a follow-up PR, I decided to split things up for easier review. Example: ```bash $ kubectl get servers.v1alpha1.metal.sidero.dev 49fd7c2d-1ba4-4157-8cc0-3f7212f119f0 -o yaml ... cpu: manufacturer: QEMU version: pc-q35-6.0 hostname: pxe-3 managementApi: endpoint: 172.25.0.1:39565 system: family: Unknown manufacturer: QEMU productName: Standard PC (Q35 + ICH9, 2009) serialNumber: Unknown skuNumber: Unknown version: pc-q35-6.0 $ kubectl get servers.v1alpha2.metal.sidero.dev 49fd7c2d-1ba4-4157-8cc0-3f7212f119f0 -o yaml ... hardware: compute: processors: - manufacturer: QEMU productName: pc-q35-6.0 system: family: Unknown manufacturer: QEMU productName: Standard PC (Q35 + ICH9, 2009) serialNumber: Unknown skuNumber: Unknown version: pc-q35-6.0 ``` We can make more changes to v1alpha2 resources in follow-up PRs. Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This is basically subset of PR siderolabs#735 with only CRD changes without actual code changes to use new CRDs. As storage version is v1alpha2, every access goes twice via conversion webhooks (for better test coverage). Other parts of siderolabs#735 will be incorporated in a follow-up PR, I decided to split things up for easier review. Example: ```bash $ kubectl get servers.v1alpha1.metal.sidero.dev 49fd7c2d-1ba4-4157-8cc0-3f7212f119f0 -o yaml ... cpu: manufacturer: QEMU version: pc-q35-6.0 hostname: pxe-3 managementApi: endpoint: 172.25.0.1:39565 system: family: Unknown manufacturer: QEMU productName: Standard PC (Q35 + ICH9, 2009) serialNumber: Unknown skuNumber: Unknown version: pc-q35-6.0 $ kubectl get servers.v1alpha2.metal.sidero.dev 49fd7c2d-1ba4-4157-8cc0-3f7212f119f0 -o yaml ... hardware: compute: processors: - manufacturer: QEMU productName: pc-q35-6.0 system: family: Unknown manufacturer: QEMU productName: Standard PC (Q35 + ICH9, 2009) serialNumber: Unknown skuNumber: Unknown version: pc-q35-6.0 ``` We can make more changes to v1alpha2 resources in follow-up PRs. Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This is basically subset of PR siderolabs#735 with only CRD changes without actual code changes to use new CRDs. As storage version is v1alpha2, every access goes twice via conversion webhooks (for better test coverage). Other parts of siderolabs#735 will be incorporated in a follow-up PR, I decided to split things up for easier review. Example: ```bash $ kubectl get servers.v1alpha1.metal.sidero.dev 49fd7c2d-1ba4-4157-8cc0-3f7212f119f0 -o yaml ... cpu: manufacturer: QEMU version: pc-q35-6.0 hostname: pxe-3 managementApi: endpoint: 172.25.0.1:39565 system: family: Unknown manufacturer: QEMU productName: Standard PC (Q35 + ICH9, 2009) serialNumber: Unknown skuNumber: Unknown version: pc-q35-6.0 $ kubectl get servers.v1alpha2.metal.sidero.dev 49fd7c2d-1ba4-4157-8cc0-3f7212f119f0 -o yaml ... hardware: compute: processors: - manufacturer: QEMU productName: pc-q35-6.0 system: family: Unknown manufacturer: QEMU productName: Standard PC (Q35 + ICH9, 2009) serialNumber: Unknown skuNumber: Unknown version: pc-q35-6.0 ``` We can make more changes to v1alpha2 resources in follow-up PRs. Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This is final part of siderolabs#735, previous part in siderolabs#823. This imports all remaining changes with some fixups minus the webhook changes. This change adds detailed hardware information to the Server CRD. Hardware info is extracted by the agent from SMBIOS. The ServerClass CRD is also updated so more precise qualifiers can be used. Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This is final part of siderolabs#735, previous part in siderolabs#823. This imports all remaining changes with some fixups minus the webhook changes. This change adds detailed hardware information to the Server CRD. Hardware info is extracted by the agent from SMBIOS. The ServerClass CRD is also updated so more precise qualifiers can be used. Co-authored-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Gerard de Leeuw <gdeleeuw@leeuwit.nl> Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
@lion7 I want to say once again thank you for your awesome job on this one. Even in the test environment the reporting of hardware information is much improved! Sorry that it took too long to merge this, but we got these changes merged with some fixups in #823 and #824 I haven't made any changes to the actual CRDs, but rather some small fixups here and there, so I believe this PR might be closed unless I missed something on the way :) |
@smira great to hear that this feature was merged! No problem on the delay, it was a huge change (and PR) after all 😅. |
No description provided.