weizhi
weizhi
Yes, all the block parts should be refactored one by one.
Found another long-running operation: Currently [the job is deleted in Foreground](https://github.com/kaito-project/kaito/blob/main/pkg/workspace/controllers/workspace_controller.go#L595-L598). We actually should delete it in background and in the following reconciliations check whether the old one still exists...
Imagine if we created 100 workspaces at the same time. All of them need to `CreateNodeClaim` and `WaitForPendingNodeClaims`, since the concurrency of reconciler is 5, if 5 workspaces are blocking...
@zhuangqh I've squashed the commits, please take another look.
The real problem is that we update conditions(status) too frequently, the anonymous function was introduced here to avoid too many `updateStatusConditionIfNotMatch` like this: ``` if updateErr := c.updateStatusConditionIfNotMatch(ctx, wObj, kaitov1beta1.WorkspaceConditionTypeSucceeded,...
Talk to the way to handle error. IMO, the webhook can use `errs.Also` to collect and return as much as possible errors. I still can't get what's the goal of...
There is another finding. I just noticed that we used `CheckNodeClaimStatus` in both `WaitForPendingNodeClaims` and `CreateNodeClaim`. IMO since we have `CheckNodeClaimStatus` in `WaitForPendingNodeClaims`, there is no need to `CheckNodeClaimStatus` in...
It's `CheckNodeClaimStatus`
No need to fail. Just return nil after creating nodeclaim. Since we watched nodeclaim, if it status changed another reconciliation will be triggered.
Actually, check status after creating can only be performed one time, because if no nodeclaim need to be created it won't be performed, but check status in `WaitForPendingNodeClaims` can always...