Deleting a network member using the controller API does not actually delete the resource.
Instead, it looks like it just does the equivalent of a GET.
I would have expected the member to be removed, and the result code to be an HTTP 204 (No Content) result with no JSON body.
Note that this is on a macOS host with the most recent code. API version 4. The member was originally created using a POST to the API.
Best example is curl trace:
garrett@garretts-mbp{11}% curl -v -X DELETE -H 'X-ZT1-Auth: 62865eee65d89bd17465264a' http://localhost:9993/controller/network/2d2f619ccc8d59ee/member/0123456789
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 9993 (#0)
> DELETE /controller/network/2d2f619ccc8d59ee/member/0123456789 HTTP/1.1
> Host: localhost:9993
> User-Agent: curl/7.54.0
> Accept: */*
> X-ZT1-Auth: 62865eee65d89bd17465264a
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: application/json
< Content-Length: 540
< Connection: close
<
{
"activeBridge": false,
"address": "0123456789",
"authorized": false,
"capabilities": [],
"creationTime": 1537894419768,
"id": "0123456789",
"ipAssignments": [],
"lastAuthorizedCredential": null,
"lastAuthorizedCredentialType": "api",
"lastAuthorizedTime": 1537894459717,
"lastDeauthorizedTime": 1537894473719,
"noAutoAssignIps": false,
"nwid": "2d2f619ccc8d59ee",
"objtype": "member",
"remoteTraceLevel": 0,
"remoteTraceTarget": null,
"revision": 3,
"tags": [],
"vMajor": -1,
"vMinor": -1,
"vProto": -1,
"vRev": -1
* Closing connection 0
}
Then if you look again, it's still there:
garrett@garretts-mbp{12}% curl -v -H 'X-ZT1-Auth: 62865eee65d89bd17465264a' http://localhost:9993/controller/network/2d2f619ccc8d59ee/member
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 9993 (#0)
> GET /controller/network/2d2f619ccc8d59ee/member HTTP/1.1
> Host: localhost:9993
> User-Agent: curl/7.54.0
> Accept: */*
> X-ZT1-Auth: 62865eee65d89bd17465264a
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: application/json
< Content-Length: 46
< Connection: close
<
* Closing connection 0
{"2d2f619ccc":1,"0123456789":3,"964474c234":1}
I have not tested this via the "Central API" yet, but that's next.
@janjaapbos Member deletion was one of the things I was adding to the proxy. But it doesn't seem to work unless this is fixed.
Does the same thing on my Mac.
Setting authorized to false and clearing ipAssignments, capabilities, and tags would be a workaround.
Since the node will keep trying to join, this is pretty much what a DELETE would accomplish.
This isn't the same thing if the node was added manually, or has been destroyed. (Meaning that the node is not trying to join.)
The DELETE method gives a chance to clean up stale nodes. When you consider the case of ephemeral nodes (which NNG can and does create), the ability to delete becomes even more important.
At any rate, the API documents clearly state that DELETE should work.
Taking a look. Should get fixed in next release.
So Central seems to lack any API support for this either. It would be nice to have it; treat it as house cleaning.
I have same behavior on Raspberry Pi using ZeroTier version 1.2.12.
Using DELETE on IP does not actually delete a member.
I can confirm similar behavior on v1.2.12 running on Ubuntu 18.04
Bump - can confirm that this is an ongoing issue with version 1.2.12
Fixed in dev
@adamierymenko It looks like the last release (on the releases tab, not sure if this is accurate) was a year ago. Is there a way to deploy the dev branch, or any ETA on when this will be merged into the public release?
Bump - could this be merged into the public release?
pretty sure this just shipped
Wasn't noted in the release notes.
Umm, in which version? I'm using the latest on repos (1.4.6) and I still get this.
Looks like it deletes it from the file, but not from memory 馃槄
This will get fixed one day :P
any update on this issue? Still not working on v1.6.2