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 the UI's deregister button #2541

Closed
slackpad opened this issue Nov 29, 2016 · 12 comments
Closed

Remove the UI's deregister button #2541

slackpad opened this issue Nov 29, 2016 · 12 comments
Labels
archived/webui This was used for v1/ui
Milestone

Comments

@slackpad
Copy link
Contributor

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.

@slackpad slackpad added the archived/webui This was used for v1/ui label Nov 29, 2016
@slackpad slackpad added this to the 0.7.2 milestone Nov 29, 2016
brianshumate added a commit that referenced this issue Nov 30, 2016
- Remove Deregister button
- Remove Deregister functionality
slackpad added a commit that referenced this issue Dec 1, 2016
@slackpad slackpad closed this as completed Dec 1, 2016
@slackpad
Copy link
Contributor Author

slackpad commented Dec 1, 2016

Fixed by #2541.

@ashald
Copy link
Contributor

ashald commented Dec 2, 2016

👍

@alexrun
Copy link

alexrun commented Apr 17, 2017

@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.

@slackpad
Copy link
Contributor Author

@alexrun we added deregister_critical_service_after (see https://www.consul.io/docs/agent/checks.html) to address that use case in an automated way:

In Consul 0.7 and later, checks that are associated with a service may also contain an optional deregister_critical_service_after field, which is a timeout in the same Go time format as interval and ttl. If a check is in the critical state for more than this configured value, then its associated service (and all of its associated checks) will automatically be deregistered. The minimum timeout is 1 minute, and the process that reaps critical services runs every 30 seconds, so it may take slightly longer than the configured timeout to trigger the deregistration. This should generally be configured with a timeout that's much, much longer than any expected recoverable outage for the given service.

@alexrun
Copy link

alexrun commented Apr 17, 2017

Perfect. I will try to enable this feature...

johncowen pushed a commit that referenced this issue May 4, 2018
- Remove Deregister button
- Remove Deregister functionality
@NarimanAB
Copy link

NarimanAB commented Feb 25, 2021

@johncowen quite a strange solution and reasoning: "Deregistering from the catalog is almost never what you want to do"
If you think the feature can be misused just protect it with ACL.

now if I want to delete a service (as it is shown here - https://www.consul.io/commands/services/deregister#)
I need call consul services deregister for each service instance. If I have 10 of them then 10 calls must be made, very user friendly!

@johncowen
Copy link
Contributor

Hi @NarimanAB

Thanks for dropping by!

Deregistering from the catalog is almost never what you want to do

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?

@NarimanAB
Copy link

@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.

UI the ability to perform actions on other agents could be a great feature to implement...

@Alexcei88
Copy link

I think it was a very useful button in the UI interface. Why removing was best solution instead of fixing any confusions.

@Ox0400
Copy link

Ox0400 commented Nov 12, 2021

have plan revert? we need this.

@allanian
Copy link

can we get a option for drop all failed services with curl maybe?

@Caceresenzo
Copy link

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.
https://github.com/crunchdao/app/blob/master/consul/scripts/unregister-button.js

The button will be visible on the health-checks tab.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
archived/webui This was used for v1/ui
Projects
None yet
Development

No branches or pull requests

9 participants