Skip to content

Draft: Rewrite MachineSetNode controller to use qcontrollers #1158

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Orzelius
Copy link
Member

a WIP draft for the #556 issue

Signed-off-by: Orzelius <[email protected]>
@@ -28,195 +30,246 @@ import (
"github.com/siderolabs/omni/client/pkg/omni/resources/system"
)

// Questions for pr
// 1. which data is stored in the spec and which in the labels?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This resource is used to extract the labels from any resource type.
In this case it's omni.MachineStatus labels.

As this controller doesn't use anything from the omni.MachineStatus spec, it can rely on the stripped down version of the resource.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I see, but is there a reason for why, for example, the evicted label shouldn't be an isEvicted field on the omni.MachineStatus spec?

Also, currently it seems that references to owner resources seem to be done using labels instead of spec fields.
For example:

  • machineSets have a LabelCluster instead of having a clusterId field in the spec
  • machines resources have a LabelMachineSet label instead of a a MachineSetId or a similar field in the spec

Is there a reason for that? Is it due to avoid having confusing zero values in the spec as the labels can be deleted?

})
machineSetId, ok := machineSetNode.Metadata().Labels().Get(omni.LabelMachineSet)
if !ok {
// maybe should log a warning. Ask in pr
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logging would be nice to have. Can also return error here. It will also be logged.

@Unix4ever
Copy link
Member

Unix4ever commented Apr 29, 2025

In general: the tricky part about the QControllers is that all inputs for the controller should have finalizers added by the QController.

So if the input is running we add the finalizer, then if the resource triggers reconcile and is tearing down, we should remove the finalizer.

The problem is that without the finalizers it is not guaranteed that the delete operation comes to the controller. It will be unnoticed by it.
I can explain that in a call if you want. This is complicated, I with we had easier to use primitives there :)

@Orzelius
Copy link
Member Author

Thank you for the review! Seems like this is not too far from the finish line so I'll take some time to try to finish this pr.

In general: the tricky part about the QControllers is that all inputs for the controller should have finalizers added by the QController.

Okay I see, this was the part I was confused about. I'll try to figure it out on my own (will learn more that way :p) and implement the changes needed and will ping you again for feedback. Thank you for taking the time to explain!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants