jbauer opened 2 years ago
|
|||||
Removing an agent at server side actually means to delete the token used by the agent. Removing by name is meaningless as agent can always connect again to get them reappear in the agent list. If agents are sharing same token, they will all be removed. This is unfortunately a side effect of sharing tokens. |
|||||
Obviously I would only delete agents that won't come back online at all or anytime soon. There are two cases:
In both cases we now have offline agents that can not be deleted without deleting the whole agent cluster. So if I reconfigure the agent docker service twice with a different hostname scheme I end up with:: and the offline agents will stay forever because I can not delete them. If I want to I have to recreate the whole thing by using a new token. It is okay'ish for me, but at least a warning should popup if an agent should be deleted that uses a shared token. Otherwise people accidentally, like me, delete the whole thing and have to recreate the agent cluster. Shouldn't there be some DB table which simply stores registered agents and we just want to delete some entries from it? Maybe they reappear if the agent still lives, but maybe the agent is indeed dead. |
|||||
Thanks for the detailed explanation. I understand your situation now. I plan to add a separate action called The current Also a new environment variable |
|||||
Robin Shen referenced from other issue 2 years ago
|
|||||
Robin Shen referenced from other issue 2 years ago
|
|||||
Also for incorrect ip address, OneDev gets ip address from I tested locally by running agent and server in same docker network |
|||||
I think the issues with the IP address is indeed no issues. When using Docker Swarm with an overlay network (so that containers can talk to each other across different physical hosts) each physical docker host has a virtual IP for that overlay network used for load balancing. These IPs can be seen when calling OneDev server only sees this virtual IP and not the container IP, which is what has irritated me. As a consequence it could also happen that two agents with different names but the same IP could be registered if docker swarm decides to deploy two agent instances on the same physical host. If OneDev server that talks to that IP docker will choose a running agent in a round robin fashion on that host. In case you are interested you can read both links below which describe how docker swarm networking works: https://blog.revolve.team/2017/04/25/deep-dive-into-docker-overlay-networks-part-1/ https://blog.revolve.team/2017/05/09/deep-dive-into-docker-overlay-networks-part-2/ |
|||||
Thanks for helping me understanding the issue. Will change OneDev to detect ip address at agent side instead of relying on |
|||||
Robin Shen referenced from other issue 2 years ago
|
|||||
Robin Shen changed state to 'Closed' 2 years ago
|
|||||
OneDev referenced from other issue 7 months ago
|
Type |
Bug
|
Priority |
Normal
|
Assignee | |
Affected Versions |
Not Found
|
Hi,
thanks for the fast update on the agent! I tried it and now all agents appear in OneDev Server. However I found some quirks though:
Agent removal might need to be done by name now? Also the token might only be deleted if it is unused. However maybe it makes more sense to ask the user if he really wants to delete the unused token. Maybe the user just wants to remove all registrations to force a new registration of all agents (but keeping the current auth token of these agents). Alternatively the token UI could add a visual label "unused" next to the token, so that a user knows it can either reuse the token or delete it. In that case OneDev server would not delete tokens automatically at all.