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.

Sign up for GitHub

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

Jump to bottom

Change operation type to update for services #224

Merged
merged 1 commit into from
Oct 2, 2024
Merged

Change operation type to update for services #224

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion internal/controllers/inventory_controller.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -896,7 +896,7 @@ func (t *reconcilerTask) createService(ctx context.Context, resourceName string)
}

t.logger.InfoContext(ctx, "[createService] Create/Update/Patch Service: ", "name", resourceName)
if err := utils.CreateK8sCR(ctx, t.client, newService, t.object, utils.PATCH); err != nil {
if err := utils.CreateK8sCR(ctx, t.client, newService, t.object, utils.UPDATE); err != nil {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Off topic/general comment...CreateK8sCR seems to do way too many things right? One func to do create, update, patch, taking ownership, doing all sorts of reflection...

Copy link
Collaborator

Choose a reason for hiding this comment

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

The purpose was to create and update objects in the same function so that the main reconciliation loop is cleaner. When you create an object, it's when you also specify its ownership, so these should be together anyway.
The inventory controller makes sure the servers exist at all times (so it recreates them if they've been deleted) and that they look as specified in the Inventory CR spec (so it updates/patches if someone edits them directly).
I suppose we could separate the updates from creation in different functions.

What enhancement did you have in mind for this?

Copy link
Collaborator

@pixelsoccupied pixelsoccupied Oct 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Few suggestions:

  • We cant say "Create" and then take an operation parameter (which happens to an arbitrary string)
  • This is not simply "Create", violating single responsibility principle. Instead we break it down into updateOrPatchObject createObject etc etc. And then finally the caller should explicitly check for errors as needed e.g. k8srr.IsAlreadyExists(err) for create
  • Given we already have access all the generated code for all CRUD reqs....we should try to use them directly instead of figure out types at runtime with Object . i.e c.Create(ctx, job) (job being a struct type job). This means more code but idiomatic/in-line with Go

wdyt?

Copy link
Contributor Author

@alegacy alegacy Oct 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

What's going to happen if we split it into a updateOrPatchObject and a createObject is that someone will get tired of seeing that pattern spread throughout the code and will create a wrapper for that flow called createOrUpdateObject and we're more or less back to this starting point.

I do agree that the name could be improved upon, and certainly how we use it will need to be addressed in the future because as of now the 'update' is rather unsophisticated and doesn't handle needing to modify objects very gracefully at all. They all end up being just a bulk replace of the object which is likely causing issues to anyone doing a watch on them (potentially)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree that renaming it to smth like ensureK8sCR would be a better description of the functionality.
I don't really agree that this is violating the SRP principle, especially with the renaming and possibly enhancing the update.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah definitely doing createObject would ultimate be wrapped up. Which is why it's better to be explicit (the third point) and pass the exact typed...so instead we should have createJob or createDeployment instead of super generic funcs

return fmt.Errorf("failed to create Service for deployment: %w", err)
}

Expand Down