Remove the UI's deregister button

[slackpad]

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]

Fixed by #2541.

[ashald]

👍

[alexrun]

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

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

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

[NarimanAB]

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

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]

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

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