-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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 the UI's deregister button #2541
Comments
- Remove Deregister button - Remove Deregister functionality
Fixed by #2541. |
👍 |
@slackpad What happen if my service were not able to deregister itself before shutting down? I have seen this scenario many times on my development consul server, where it keeps lots of failing instances that are never going to disappear. I suggest Leaving the button for commodity and not having to make the manual call to the /v1/catalog/deregister API and probably improving the confirmation message for those cases where the user gets confused. |
@alexrun we added
|
Perfect. I will try to enable this feature... |
- Remove Deregister button - Remove Deregister functionality
@johncowen quite a strange solution and reasoning: "Deregistering from the catalog is almost never what you want to do" now if I want to delete a service (as it is shown here - https://www.consul.io/commands/services/deregister#) |
Hi @NarimanAB Thanks for dropping by!
Generally if you are deregistering services you should deregister from the agent. If you deregister from the catalog, in all likelihood the service will just be added back to the catalog by the agent via anti-entropy. So its not so much that you could just protect a button/API call via ACLs, more that it is can be confusing for a user who thinks they are deregistering a service only to see it appear again as its added back via anti-entropy. The command you reference above removes the service instance from the agent, not the catalog, which is the important point here. From the UIs standpoint right now it mostly can only perform actions on the agent that it is running on, so the UI would only be able to deregister one of the ten service instances (if you have ten separate nodes/agents). Overall we have spoken as a team about giving one instance of the UI the ability to perform actions on other agents, but adding that ability is not trivial. Does that help to give context to the decision here? |
@johncowen Thanks for the reply. If UI button was capable to deregister only one instance, I totally agree that was misleading. I thought I could deregister the whole service from UI. It was not clear for me that I saw info from all agents/nodes (list of service instances) but could do actions only on the node I connected to.
|
I think it was a very useful button in the UI interface. Why removing was best solution instead of fixing any confusions. |
have plan revert? we need this. |
can we get a option for drop all failed services with curl maybe? |
I know this issue is old, but since they do not seems to add the button back. I made a small Tampermonkey script that add the missing button to deregister any service. |
Deregistering from the catalog is almost never what you want to do, so this button causes a lot of user confusion. We should just remove it.
The text was updated successfully, but these errors were encountered: