Play fails to uninstall service/agent when changing an existing agents pool

[TJEvans]

When using an agent name with a '-' in it this gets translated to \x2d in the service name. The identified task is used to determine whether the service needs to be uninstalled/installed and is failing to detect it when these character translation take place.

1) Setup agent with '-' character in name using role 2) Re-run role with recreate variable set to true. I expect the service to uninstall and re-install. The uninstall is not happening and the install is failing since it already exists

[TJEvans]

Assuming systemd-escape is suppose to be handling this but i'm playing around on CentOS so Ill assume that is the problem until I find out otherwise

[TJEvans]

Failure described was a result of attempting to change the agent pool name. The service is installed as vsts.agent.myaccount.foo.agent-1.service, I re-run modifying the pool name, to bar. This results in a search for the service vsts.agent.myaccount.bar.agent-1.service, which reports not installed. Unistall doesnt run, then install fails due to pre-existing service.

Potentially a red herring due to https://github.com/gsoft-inc/ansible-role-azure-devops-agent/issues/19 will follow up

[TJEvans]

I have re-defined the issue. If I try to use this play to replace the agent on an existing agent AND change its pool name at the same time I fail to remove the existing agent since the service_is_installed flag reports false in this scenario. I am also curious now how this is managed in the case of deployment agent, since the service name is tight bound to a build pool value.

[TJEvans]

Had success changing your if statement to use the glob pattern search below if [ ! ls "/etc/systemd/system/$(systemd-escape vsts.agent.{{ az_devops_accountname }}.*.{{ az_devops_agent_name }}.service)" 1> /dev/null 2>&1 ]; then

[yohanb]

Hi @TJEvans, I tested on my side and the match wasn't working. Also, I'd rather use the provided script svc.sh to get the status instead since it abstracts having to know the name of the service. If ever they decide to change vsts.agent... to azdevops.agent... we would have to follow their naming pattern. Finally, I think supporting having to change an existing agent's name or whatnot is more of an egde case.

[TJEvans]

Happy to push it back to MS to resolve with recommendations. I agree changing the pool an existing agent is assigned to is an edge case, happy to leave it up to you whether to handle or not. I also found in further testing the command referenced in my comment above didnt work and submitted a variation in the referenced pull request. Let me know if you would like me to take any action, but from my perspective this was resolved with the above pull.