Skip to content
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

Refactor cfprocess controller #3801

Merged
merged 1 commit into from
Feb 17, 2025

Conversation

uzabanov
Copy link
Contributor

Is there a related GitHub Issue?

#1949

What is this change about?

  • Use a single app workload var instead of deep copying objects, which
    is confusing

  • Instead of using controllerutil.CreateOrPatch, implement a similar
    behaviour ourselves

    • By first trying to creaate the new appWorkload, we avoid a potential
      race
    • We know that we are going to need fine control over what fields are
      being mutated on create vs update
  • Also add a new TryPatchResource utility that can handle an error
    returned by the modify func

return nil
}

func getProcessInstances(cfProcess *korifiv1alpha1.CFProcess) int32 {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe ZeroIfNil?

desiredAppWorkload, err = r.generateAppWorkload(actualAppWorkload, cfApp, cfProcess, cfBuild, appPorts, envVars)
if err != nil {
log.Info("error when initializing AppWorkload", "reason", err)
if err = r.modifyAppWorkload(appWorkload, cfApp, cfProcess, cfBuild, appPorts, envVars); err != nil {
Copy link
Member

Choose a reason for hiding this comment

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

modifyAppWorkload function name sounds a bit weird to me. What this function does is that it applies desired state onto the app workload, which is what reconciliation in general is all about. How about reconcileAppWorkload? Or maybe applyToWorkload?

- Use a single app workload var instead of deep copying objects, which
  is confusing
- Instead of using controllerutil.CreateOrPatch, implement a similar
  behaviour ourselves
  - By first trying to creaate the new appWorkload, we avoid a potential
    race
  - We know that we are going to need fine control over what fields are
    being mutated on create vs update

- Also add a new TryPatchResource utility that can handle an error
  returned by the modify func

Co-authored-by: Georgi Sabev <[email protected]>
@georgethebeatle georgethebeatle merged commit 5c45edf into main Feb 17, 2025
10 checks passed
@georgethebeatle georgethebeatle deleted the issues/refactor-process-controller branch February 17, 2025 13:45
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.

3 participants