Force Deregistration of service - services won't remove

Consul
1

I am trying to remove some services that were added to consul manually via a json file. I have tried to run both of these commands with no success. I need a way to purge these values. Please if you can help I would be very greatful.

Brad

consul services deregister  service_registration.json
and
consul services deregister -id=grafana

The cli shows being deregistered but when I go to look in the ui, they are still there. And when I go to try to register the corrected version, it adds it to the existing service that I am trying correct.

This is the broken one I am trying to replace.

{
   "services": [
      {
         "id": "grafana",
         "name": "grafana_vpc",
         "tags": [
            "primary"   
      ],
         "address": "10.10.10.2",
         "port": 8600,
         "check": {
            "id": "grafana",
            "name": "Consul DNS tcp on port 8600",
            "tcp": "10.10.10.2:8600",
            "interval": "10s",
            "timeout": "1s"   
      }  
    }
  ]
}

This is the corrected one.

{
   "services": [
      {
         "id": "grafana",
         "name": "grafana_vpc",
         "tags": [
            "primary"   
      ],
         "address": "10.10.10.2",
         "port": 3000,
         "check": {
            "id": "grafana",
            "name": "Consul DNS tcp on port 53",
            "tcp": "10.10.10.2:53",
            "interval": "10s",
            "timeout": "1s"   
      }  
    }
  ]
}
2

Hi @bradley Registered services are persisted in the agent state directory. If the state directory remains unmodified, registered services will persist across restarts. So what you could do is do is re-create that client node.

The consul services register/deregister command are targeting the local Consul agent and the /agent API endpoint. If you register the service using the API and the catalog endpoint you can avoid behavior and leverage the catalog deregister endpoint.
But we recommend the agent endpoint due to it using anti-entropy. Most instances the underlying infrastructure is ephemeral so the VM or container tends to be re-created thus avoid this issue.