Worker deployments should override any existing service definitions if the name is the same
Closed this issue · 5 comments
While troubleshooting a deployment on a box that had an existing deployment, I noted that a new deployment under a new linux user and critically, the same worker_service_name, did not override the existing service definition.
This could be a source of confusion, especially when troubleshooting because the original (possibly broken) deployment will end up running.
In short:
If the deploying user specifics a given service name already in use, it should overwrite that definition.
Is this about running using a different worker_username than a previous installation?
Yes, which if that is not supported, requires awareness of previously used settings or manually sshing into the target server.
yes, this is not easily possible as ansible is not a stateful deployment. It's is no aware what happened previously in the system. The work to make this work would be quite complex as it would require trying to figure out if the service exists anywhere else in the system etc.
In general this is bad ju-ju to maintain. The proper way is to ensure that changes on a system do not happen outside ansible and therefore avoid creating "snowflake systems" and therefore that the people always know where the system is running.
In case we know another user already exists which is running it, then it should be manually cleared up, or more optimally the system should be Restroyed.
I'm not following; if the service name already exists, just overwrite it. This workflow ends up getting root at some point; do it with an elevated context
These services are in userspace. A different user cannot "overwrite" the service of another user. The only approach here is to delete the service from the first user and create it on the other user. As I explained in discord, this sort of things is bad practice from an ansible perspective.