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

restartmanager: Remove RestartManager interface, and unused error return #42264

Merged
merged 3 commits into from Jan 10, 2023

Conversation

thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Apr 7, 2021

  • restartmanager: RestartManager.Cancel(): remove unused error return
    This function would never return an error, and no code was handling errors.
  • restartmanager: add SetPolicy() to the RestartManager interface
  • container.UpdateMonitor(): don't instance restartmanager if not needed When updating a container to set a "no" restart policy, and the container does not have a restart-policy set, there should be no need to instance a restartmanager. (removed)
  • restartmanager: remove RestartManager interface; it only had a single implementation.

- A picture of a cute animal (not mandatory but encouraged)

@thaJeztah thaJeztah added status/2-code-review area/daemon kind/refactor PR's that refactor, or clean-up code labels Apr 7, 2021
@thaJeztah thaJeztah changed the title Update the update daemon: some refactoring in RestartManager / updating restart policies Apr 7, 2021
@thaJeztah
Copy link
Member Author

I can remove the interface as there's only one implementation

@thaJeztah thaJeztah force-pushed the update_the_update branch 2 times, most recently from 132dd1c to 40cc95f Compare February 10, 2022 16:30
@thaJeztah thaJeztah changed the title daemon: some refactoring in RestartManager / updating restart policies restartmanager: Remove RestartManager interface, and unused error return Feb 10, 2022
ShouldRestart(exitCode uint32, hasBeenManuallyStopped bool, executionDuration time.Duration) (bool, chan error, error)
}

type restartManager struct {
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm guessing it was using an interface (exported) and restartManager type (not exported) to enforce that it had to be initialised through .New(). Not sure if that's worth the extra complexity though (but open to feedback)

Copy link
Member

Choose a reason for hiding this comment

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

Hmmm do any of the linters we're using have a way to help enforce that? I guess maybe we're probably not even using this in enough places to really worry about it?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I don't think we should worry about this. It's (somewhat) inherit to how Go work, and it not being "really" OO; I guess we have any types that are only functional / usable when using a constructor (or being sure all fields are set), and nothing really prevents someone from just foo := SomeType{} without setting those fields.

I think the change in this PR outweighs that theoretical "issue".

@thaJeztah thaJeztah marked this pull request as draft February 11, 2022 07:14
@thaJeztah

This comment was marked as resolved.

@thaJeztah thaJeztah marked this pull request as ready for review March 11, 2022 18:52
@thaJeztah
Copy link
Member Author

@cpuguy83 @tianon ptal

Copy link
Member

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

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

LGTM

This function would never return an error, and no code was handling errors.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It only had a single implementation, so we may as well remove the added
complexity of defining it as an interface.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah merged commit d73aba2 into moby:master Jan 10, 2023
@thaJeztah thaJeztah deleted the update_the_update branch January 10, 2023 10:40
@thaJeztah thaJeztah added this to the v-next milestone Jan 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/daemon kind/refactor PR's that refactor, or clean-up code status/4-merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants