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

Remove common.Daemon from Monitor interface #4084

Merged
merged 1 commit into from Mar 28, 2023

Conversation

MichaelSnowden
Copy link
Contributor

What changed?

Why?
The Start and Stop methods of the Monitor shouldn't be required because it should be up to implementors how a monitor is started and stopped. Currently, our RingPop monitor already does this by using fx, so we don't even want users of the package to call Start and Stop in an adhoc manner.

How did you test it?
I stepped through with a debugger and verified that the call to Start in the worker service was a no-op because start is already called as part of the fx lifecycle. I could not verify the Stop logic because I don't think Stop is even called when we shut down the server.

Potential risks

Is hotfix candidate?

@MichaelSnowden MichaelSnowden requested a review from a team as a code owner March 22, 2023 17:46
@yiminc yiminc requested review from rodrigozhou and dnr March 23, 2023 15:49
Copy link
Contributor

@rodrigozhou rodrigozhou left a comment

Choose a reason for hiding this comment

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

I don't quite understand what's the issue with this implementation. As I understand, the monitor/daemon has a Start/Stop interface to start/stop the daemon. What do you mean that "it should be up to implementors how a monitor is started and stopped".

rpcConfig *config.RPC
tlsFactory encryption.TLSConfigProvider
dc *dynamicconfig.Collection
monitor *monitor
Copy link
Contributor

Choose a reason for hiding this comment

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

Why change this to the struct type instead of keep the interface type?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To have access to the Start/Stop methods which are no longer in the interface

@MichaelSnowden
Copy link
Contributor Author

I don't quite understand what's the issue with this implementation. As I understand, the monitor/daemon has a Start/Stop interface to start/stop the daemon. What do you mean that "it should be up to implementors how a monitor is started and stopped".

The idea is that users of the interface should not need to know about Start/Stop because every time they use the object it should be ready because of the fx lifecycle management. Additionally, implementations shouldn't need these methods because they should manage the lifecycle themselves via the fx Hooks they add. This will make it easier to replace our existing monitor implementation as well. Some implementations may want to use the context from fx.OnStart as well.

@rodrigozhou
Copy link
Contributor

rodrigozhou commented Mar 24, 2023

The idea is that users of the interface should not need to know about Start/Stop because every time they use the object it should be ready because of the fx lifecycle management. Additionally, implementations shouldn't need these methods because they should manage the lifecycle themselves via the fx Hooks they add. This will make it easier to replace our existing monitor implementation as well. Some implementations may want to use the context from fx.OnStart as well.

I don't see why exposing Start/Stop is in any way bad. In fact, I think exposing gives more flexibility to the user to work with the daemon. Is there any issue y calling Start/Stop multiple times? They should be idempotent.

In any case, I don't have much context on this, so no strong feelings about it.

Copy link
Member

@dnr dnr left a comment

Choose a reason for hiding this comment

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

I'm with Michael: I don't think our use of common.Daemon has any real value anymore. We should keep moving towards using fx for all lifecycle management

@MichaelSnowden MichaelSnowden merged commit afc5ac7 into master Mar 28, 2023
7 checks passed
@MichaelSnowden MichaelSnowden deleted the snowden/resolver-3 branch March 28, 2023 17:08
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.

None yet

3 participants